2023-BUAA-ooPre课程总结

架构设计与调整

架构设计说明

• Main类用于集中处理输入，并由方法Option1~21实现对应指令；

• Bottle, Food, Equipment, Adventurer类均为Commodity接口的实现，Equipment与Bottle类分别下设三个子类，设有相应属性与功能；

• Adventurer类除了实现Adventurer继承自Commodity的属性及方法，还集中实现了所有对Bottle, Food, Equipment的操作；

• FightLog类集中处理战斗日志的load+match操作；

• Store类负责实现与Commodity交易记录有关功能

架构调整与反思总结

• 在我的代码中，仅仅在新增FightLog类时对架构调整较大，此外整体架构基本保持不变。

• 在增加FightLog类之前，我试图在Main类中实现查询载入、查询战斗日志的全部功能，经实践证明这样会导致代码可读性严重降低，并且为后续debug带来了巨大负担。在FightLog类中，实现了判断并录入合法战斗日志、匹配并查找符合要求战斗日志的功能。

• 实际上，我的架构是具有进一步细化空间的。与其他同学的代码相比，我的实现中类的数量显然是较少的，这样当然使得后续迭代中新增方法比较容易，但也导致了部分类中代码量明显过大——比如，我的Adventurer类几乎包含了所有对Bottle/Food/Equipment的使用、携带、丢弃等操作，因此可读性、可维护性都有一定程度的降低。

• 就调整思路而言，可以将Adventurer类中对不同Commodity的操作单独提出作为一个类；也可将FightLog类进行类似的细化操作。

junit使用心得

• 在课程的学习中，起初我对写junit测试比较抗拒，尤其对于覆盖率不能达到要求时痛苦万分；但逐渐在实践中发现junit的独特优势就在于覆盖率测试。

• 目前我调试代码的方法主要是针对未通过的数据点利用idea的断点调试功能定位bug，同时将junit覆盖率测试作为调试代码的辅助工具。我的junit测试数据主要来自课程平台上公开的数据点，其优势就是覆盖率足够高，有助于更高效地找到bug的大致位置。

• 必须承认，我对于junit测试应用还是不够到位的。比如，我的数据点来源比较单一（都是历次测试公开的数据点），这样就可能出现我某次写下的bug在若干次迭代后才会暴露出问题的情况。在OO正课的学习中，我认为我需要锻炼自己全面考虑各种可能情况，并主动写数据点进行junit测试的能力，以便于将junit的效益最大化。

oopre学习心得

• 对面向对象的理解：

在本课程的学习中，我初步接触到了从面向过程编程到面向对象编程的思维转变。面向过程编程的思维类似于”走一步看一步“，只需要借助函数逐一实现解决问题的各个步骤再进行组装即可。相比之下，面向对象与此有显著差别：它要求我们以”对象“为中心思考，从问题中抽象出相应的对象，通过实现对象各自的方法解决问题。面向对象的特点在于虽然牺牲了部分性能，但当问题规模较大时，显然更加便于进行维护和扩展。

• 版本控制和代码风格检查：

在oopre课程学习中，我初步接触到“版本控制”的概念，并且认识到其在未来软件开发多人协作中的重要作用。此外，我也认识到代码风格检查不仅有助于提升代码的可读性，更能够降低迭代开发中进行维护、扩展的成本。

• 学习过程中的不足之处：

本学期的迭代开发式面向对象编程作业中，虽然我能够基本熟练地用运用相关知识解决问题，但我认识到面向对象编程练习的目的不应仅仅只是成功地解决某一问题（通过数据点），更重要的是学会分析迭代开发的需求，在写代码前进行充分的规划与设计，并在实现前认识到某种方案潜在的危险性，否则便容易导致写代码以及后续debug、调整架构时付出高昂的时间成本（比如在Adventurer类的equipmentBag中，我采用HashMap<String, Integer>维护背包中的装备，导致后续de有关bug过程极其艰难）。总而言之，在提前进行合理的架构、方案设计这方面，我还需要进一步提炼总结——当然，这也应建立在进一步熟悉java相关语法的基础上。

对oopre课程的简单建议

• 课程引入时指导书内讲解了大量有关git的内容，但是其中关于命令行的内容对于新手而言可能因缺乏足够铺垫而晦涩难懂（比如其实我到现在也只会借助idea的版本控制功能提交作业），如果在这一部分内容设计更有层次感一些会更好~