作业最终的架构设计

经过轮轮迭代，面向对象先导课程也终于走向了尾声。

关于类

本次迭代任务中，共有24个类被创建：

他们分别是：

• MainClass: 程序入口，实现数据读入操作和大量核心方法。
• Adventurer: 核心操作对象，内含有关Bottle，Equipment，Frag，Employ类的相关容器
• Bottle：内设三个子类，HpBottle，AtkBottle，DefBottle
• Equipment：内设三个子类，Axe，Blade，Sword
• Frag：表达碎片的相关属性与方法
• Employ：表达雇佣关系相关属性与方法
• Guard，Treasure及其Factory：秘境探险操作中的新对象

具体属性就不详细说了

关于容器

在容器上的考虑，值得一提的便是CarriedEquipment。它使用了以name为索引的HashMap，这一方法十分契合题设要求。可惜的是，在处处以id为核心标识的情境，使用以name为索引的方法不可避免地要处理好在carry操作之外的重名问题。

那便是deleteEquipment()方法在第三次迭代强测中带来的惨痛教训

关于迭代

迭代式开发的课程，着实是令我耳目一新的。

• 第一次迭代 OMG，it’s LLM! 从第一次迭代时拙劣地模仿IDEA的LLM，到现在理解较为成熟地模仿LLM，大家每个人的进步都是肉眼可见的。

• 第二次迭代

  • 添加了carry指令。当时没有想太多，直接为装备添加了isCarried属性（谁能想到后面装备还能援助给别人呢（）
  • deleteCommodity()让我开始考虑将Bottle和Equipment结合起来，但其差异仍将大于其共性。

• 第三次迭代 这次迭代是让我最印象深刻的一次迭代，痛失40分（苦笑 核心要点主要是： 容器重构，carry，frag，fight

  • 删掉了所有find函数，用上了高效简洁的HashMap
  • carry方法重写，建立了专属容器以存放Carried的物品。关于carriedEquipment以name为索引的潜在问题前面已经提到了。
  • frag的处理。就忽略id属性这一问题，我认为是合理的。frag的最核心属性就应该是name和count，以同名frag作为一个对象基本单元，在获取数量，消耗数量等操作上都是合理的。不过把id忽略掉这种行为本身，对于整个项目来说，可能还是有一定隐患的。
  • fight较为简单。强测错因是getAtk()误写成getCe()。

• 第四次迭代 迭代任务确实一次比一次重

  • 雇佣关系：建立Employ类，对于一个雇佣关系对象本身管理它的各项属性。这种思想让我缓了很久，万物皆为对象！曾经室友写了一个Fight类，让我懵懂地理解了一下什么是过程对象，如今自己写的时候又更明白何为关系对象。把一场战斗（函数(函数其实也是关系，关系就是有序对)）当作一个对象，它有它的属性，有它的方法；把雇佣关系（有序偶对）作为对象，同样有自己的属性与方法。
  • 递归攻击：倒是一个很容易克服的难点。
  • 秘境探险：更多的是一种思想认知的改变，在具体实现上让我对接口有了新的认识。不同的类可以借助接口同一调用不同内容的方法，确实便利了很多

中测de了半天bug原来错在getComprehensiveCe()也是没谁了（）

使用JUnit的心得体会

覆盖率是一项任务

起初，我确实没有意识到JUnit的功能。能在运行中构造样例运行出来的结果，为什么还要搞那么复杂去专门去测？我对各个方法进行了无意义的测试，完成了基础任务。

覆盖率赋予每一行代码意义

自第三次迭代作业开始，加入了分支覆盖率的要求。在我开始思考覆盖率的意义之时，我方才意识到，单元测试之所以是单元测试，便在于它使得代码中各种细微的地方都能被顾及得到。同样，覆盖率也能够帮助我写出更完善的测试代码。

单元测试，但不仅仅是单元

在单元测试中，我们不仅要编写对于单个方法的测试，更需要对较大的方法进行测试，在大方法中测试小方法相互作用关系的正确性。单元测试中的单元不仅是指最小单元，更是单元之间组合形成的层次化结构单元。

测试数据构造需要技巧

无论何时，以debug为目的的测试终究是要找到bug。因此要尽力去构造bug相关的测试点，构造较极端的情况进行分析，而不是为了达到覆盖率要求而进行大量的无意义测试。

学习OOpre的心得体会

以方法为核心的逻辑

在学习C语言的时候，我曾畅想，如果各项基本操作都能靠函数实现，而函数的实现也依靠其他函数，人脑只需负责顶层逻辑，那些条条框框的小方法被封装起来等着用该多好…

在OOpre的课程中可谓是函数方法用的最多的一集，有大量好用的被封装好的方法，我只负责对方法进行封装，构造新的方法，再调用方法…
因此，在debug时，C语言和OOpre两门课带给我的感受是很不一样的。前面是对于方法具体实现细枝末节的深深考究，而OOpre的思路总是流畅贯通，哪里有问题它可以根据逻辑分析直接推理出漏洞

以对象为主体的视角

这一点，是我在第四次迭代中深刻体悟到的，万物皆为对象。前文已有讲述。

课程建议

希望可以像CO一样提前有一定的基础知识学习期，提供资料自学容器，子类，接口等内容的基础知识，解决课上刚学会的知识总是不能快速理解运用的问题。