面向对象先导学习心得

架构

• 指令使用注册表Registry。添加新指令只需向注册表中加入新的指令实例，保证指令之间不相互干扰，各指令逻辑独立在不同的文件中
• 药水和法术使用注册表。这样可拓展性好，逻辑清晰
• 指令的输出提取为专用于输出的报告类Report，让指令聚焦于逻辑而非数据和输出，交互逻辑和展示输出是相对独立的两个部分，使指令返回报告类，然后调用报告类产生输出
• 指令使用依赖注入。指令在一定的环境Context中运行，在此项目中环境就是全体冒险者构成的List，然而指令并不关心环境到底是哪个，因此指令不应该直接访问某个类中特定的public static的冒险者列表，而是在实例化时将冒险者列表作为参数传入构造函数，这样就解耦了环境和指令逻辑
• 每个类该有什么行为就有什么行为，不要刻意避免连续调用，连续调用例如指令调用冒险者的use，冒险者调用物品的use，因为，抽象地看，使用这个行为是冒险者和物品都应该有的行为，具体过程不关心；具体地看，冒险者只管如何「使用」物品，而物品如何「工作」是冒险者不关心的，应当封装到物品内部。这样可读性最好、逻辑最明确
• 不要使用if-else枚举类型，例如枚举是bottle还是equipment，这意味着代码还不够抽象且不利于拓展

JUnit

测试代码应当覆盖全面，测试数据要足够强，并在每次修改代码之后都测试，以第一时间发现bug。

课程心得

面向对象注重抽象，不关心如何做到，只关心能做到什么，极致的体现就是interface，将「我能做到这些」暴露给外界的有机整体即为类。

将public属性改为private并暴露getter和setter不应当视为封装的一部分，而应当视为Java Bean等规范失误导致的冗余。

加入新功能时，尽量做到「只新增，少修改」，对修改封闭、对扩展开放。

使用父类复用逻辑并不一定是最好的，当复写父类方法时，每个子类都要调用super.function()仍然是一种冗余。组合优于继承，可以去掉子类，将子类变成无继承关系的其他类，即一个个功能模块，在实例化时通过依赖注入，提供这些功能模块：new Bottle(someEffect)，这样更为灵活，甚至可以实现复合效果：new Bottle(effect1, effect2)

课程建议

• 建议讲授更多工程化和架构相关内容，告诉学生什么样的架构是好的、是易维护易拓展的，又该如何评判代码是否「低耦合高内聚」，否则学生难以自己想出未曾见过的东西
• 允许使用反射，这将简化许多逻辑，例如可以简化掉工厂类，也可以实现自动检测已死玩家，或是通过注解优化指令解析。作为应对，使用反射hack测评机的学生按照学术不诚信处理