OOpre第八次作业

[何劲杉-24373530]

 一、最终架构

关于具体对象类，Item这一父类的诞生，来源于课程作业中物品管理的遍历需求，以及携带的需求。最开始将Spell也置入Item类，并且在每次实例化Spell时默认携带Spell。然而后来，由于对背包中物品的种种管理要求，也为了严谨化Item这一描述，将Spell单独分离开来成为一个类。在Bottle和Spell下，分有许多实现具体功能所用的子类。这里为每一种效果单独设置一个子类是由于课程中的教学如此。就我个人意见，对于效果种类较少的项目，这样会更加醒目更加便于管理；然而如果效果种类较多，或许为每种效果单独创建一个类会显得过于冗杂。以此处药水为例，四种药水可以合并为“属性增益药水”一个类。

关于操作方法类，Solver是专职为处理解析输入而创造的一个类，内部有大量private方法用于把外部输入和操作联系在一起。Factory类则通过提供静态方法，来创建各种具体对象。该类尤其在“buy”指令的执行中发挥重要效果。最后的Lexer则为“lr”指令服务，用于解析其相关输入。把这些具有固定作用的方法单独划分出来成为一类，有助于提高代码可读性。Solver中有一些较复杂的指令，需要调用不止一个函数来解析其输入。或许将它们也像Lexer一样独立出来划分为新的类，会使代码可读性与可维护性更高。

二、Junit心得

尽管在工作量上稍显繁琐，但是Junit测试的效果是显著的，也有利于在编程时立即测试自己的代码片段，检验其是否达到自己期望的效果。不过，由于习惯原因，比起使用assert断言，我更关于在测试中通过输出内容来检验程序效果。另外，Junit要测试private方法会极其麻烦，只能以间接方式测试，不能直接调用方法本身。这个问题在我大量使用private方法之后才发现。若非为了代码风格一致性与安全性（后者实际上在OOpre作业中并不成为一个问题），全程使用public方法完成作业会更加轻松。

三、OOpre心得

Java是门好语言。Java之中不同于C的“类”的思维方式，比起C中的“函数”与“结构体”，提供了更加抽象而泛用的工具。其语法与C也较为相似，只是在遍历时需要留意迭代器的相关知识，比起各种更加底层的语言，从编写难度到测试难度都要友善得多。然而，Java中需要时刻留心“对象”的意识，如浅克隆与深克隆的相关问题。搞明白什么时候该实例化，什么时候该创建一个新的对象，就已经搞懂了Java一大半的架构问题。

四、课程意见

有些指导书篇幅过于长了，一眼难以捕捉到关键的整体信息。建议妥善使用超链接，或者内容自带展开与折叠功能，方便学生把握全局信息。否则，在看到作业中具体的需求之后，再要回顾教学部分思考实现方法，会较为麻烦。