一. 架构设计
1.1 架构示意图
1.2 架构调整及考虑
前三次作业按照指导书的要求正常迭代,没有出现问题。
第四次作业引入FightLog类,一开始并没有正确理解“战斗模式”的概念,只创建了一个日志的实例,将每次战斗模式的有效日志都存放在这一个示例中,导致了后续查询操作的混乱。此时注意到Main类方法过于集中,开始考虑解决办法。
第六次作业主要新增了子类和接口,对于战斗日志的问题进行了小幅度改动,但逻辑仍然有问题,由于时间问题未能彻底修复。考虑到方法过于集中在Main类,所以设置了新的类Demon,把Main中的方法全部移植到Demon,Main仅保留入口。
第七次作业新增Store类并实现了观察者模式,对于所有涉及到战斗模式的内容进行了正确的重构,优化了过于冗长的方法,并为所有改动的方法重新编写了JUnit单元测试。
二. JUnit使用心得
最初只是为了满足覆盖率的要求,为每个方法都编写了单元测试,但并未考虑利用测试寻找bug,而是依赖断点调试。
后期开始强测,由于数据量过大导致断点调试效率过低,加上大范围重构方法,所以重新以debug为导向去编写测试。事实证明,当代码复杂度增加,测试点数据量增大时,使用JUnit测试是一种更高效的debug途径。
三. OOpre学习心得
虽然吴老师在课堂上经常强调面向对象编程的封装、继承、多态等特点,我在初期编写java代码时仍然无法摆脱面向过程编程思想的影响,甚至曾在一个方法里嵌套了三层for循环。
后期随着任务难度的增大,我深刻体会到了面向过程的代码在维护过程中带来的困难。在课程压力的倒逼下,我开始强迫自己理解面向对象的思维,并且对写的不好的方法进行了重构,最终实现了预期的需求。
这门课程的学习最终使得我完成了从面向过程到面向对象的编程思维转变,对庞大的工程项目的开发和维护有了一定的了解,期待后续OO正课更加深入的学习。
四. 对OOpre课程的建议
建议在每次迭代任务结束时给出一个合理的需求实现思路供同学们参考和反思。有时候一昧闭门造车容易导致钻进牛角尖,甚至连着几次迭代都不能彻底解决某些问题。给出一个基本的参考思路应该可以避免这种情况。