BUAA面向对象设计与构造先导课结课感悟
最终架构设计
架构类图
类图的方向是方向从上到下。
\
通过主要实现功能分类，我的工程可以分为以下几个部分：
输入解析：AdventureGame类提供程序入口，并进一步调用Solver类进行输入解析。
冒险者：游戏的主体。主要的行为基本都是通过调用Adventuer类进行实现的。
物品：可以被放入背包、有战斗力的东西。包括Equipment类和Bottle类，这两个类再通过继承模式产生子类，包括Axe类、Sword类、Blade类、Atkbottle类、Defbottle类和Hpbottle类。
碎片：不能携带、无战斗力。对应Fragment类
副本：冒险者挑战的副本。底层包括TreasureFactory类、Dungeon类和Guard接口，再从Guard接口和TreasureFactory类衍生出五种系统怪和对应宝物。
架构调整及考虑
我的想法是根据操作的主体进行划分过程实现的划分，让每个主体做自己要做的事。前几次迭代其实都是在原来的框架里添加新的内容，没有特别的调整操作。以下是后期几次作业的架构调整。
第五次作业
第五次作业对背包有了进一步的要求。原本我是通过几个不同的Hashmap实现仓库和背包，这次作业还对背包内的物品名称有限制，于是我又加了几个Hashmap实现名称和物品的映射，因此我在每次修改背包和物品的地方都要增加对新的容器的修改。但是我在迭代的过程中漏掉了几处的修改，导致强测没过。事后想想其实这几个容器功能重复，可以把几个Hashmap进行合并、统一，形成一个新的类，然后让这个类支持编号和名称关键字的查找。
第六次作业
第六次作业增加了一个增加冒险者属性的物品：使用战利品。之前也有通过使用对应属性的药水进行属性增加，但是当时我写的代码是直接在类的内部修改属性。后面我把冒险者三维属性的修改都抽象成了不同的方法，这样可以增强可读性和拓展性，要增加属性的时候调用对应冒险者的对应方法即可。
关于第六次的“宝物工厂模式”，其实在前几次作业也有类似的需求：要通过物品type来决定生成的不同的物品类。这部分代码也可以进行重构，便于后续迭代。
JUnit的使用心得体会
- 从底到顶：在编写JUnit的时候，可以从最底层的方法开始编写。完成最底层方法的测试后，再进行高层方法的测试，或者通过底层的方法测试高层的方法。这样可以更精确地定位到导致JUnit不通过的bug的位置。
- 覆盖充分：JUnit的测试样例需要尽可能地覆盖更多的行、分支和方法。同时，可以在符合题目要求的情况下，JUnit的数据样例可以尽量从边界量、堆量的随机量入手。
- 尽信JUnit不如无JUnit：JUnit能帮助您找出bug，但是您通过了JUnit测试不代表您的方法不存在逻辑上、细节上的问题，也不代表您的程序在执行方法的时候不会出问题。如果您的JUnit比较单薄，请不要过度相信您的JUnit测试结果。我建议编写JUnit时可以多花一点心思，特别是一些比较长的方法的JUnit，并在编写JUnit时抱着hack自己代码的宿命感，从各种可能会产生BUG/实现功能的角度进行测试。比如，我要根据条件转移一个东西，我得分析条件是否会生效，转移≈A失去+B获得，我得检测是否A是否失去，B是否获得。
OOPre的学习心得体会
- 从面向过程编程过渡到面向对象编程的体会：同样面对一个问题，在面向过程编程的过程中我主要关注的是如何实现解决问题的步骤，而在到面向对象编程的过程中我主要关注的是对象以及对象之间的交互行为，重点是如何合理地把问题划分成各个对象。面向对象编程能很好地化简一些比较麻烦的逻辑过程的实现。
- Checkstyle：课程对我们的代码提出了代码风格要求。虽然是硬性的要求，但是我在迭代开发的过程中也逐渐认识到了良好的代码风格对代码可读性的显著提升作用。
- OO三大法宝：封装、继承和多态。感觉都是为了降低工程内部复杂性和提高可拓展性的模式。在设计框架、重构的过程中我们应该尽量遵循这三个模式，提高代码的质量。
课程建议
- 关于“设计模式入门”的内容是不是可以在我们开始迭代的前几次作业时候的稍微涉及一下，或者让我们提前了解。我觉得这个内容应该是一个比较重要的内容。在后期Lec6讲解确实可以让我们通过已经几乎成型的代码对比进行比较，在比较的过程中得出设计模式的优势，并且驱使我们去重构自己的代码结构。但是我们可能不能很好地体会到设计模式在迭代开发过程中的优势，也不能体会到设计模式迭代开发时的迭代思路。希望能在迭代过程中加深对设计模式的理解。
