一、最终作业的架构设计与迭代中的调整及考虑
架构设计
Main类调用MyScanner和Manager,Store采用单例模式。
- MyScanner:初步解析输入信息,将处理好的信息传入CmdUtilArray。
- Store:采用单例模式,只负责和Adventurer进行交易。
- Manager:管理Adventurer和FightLog。handleOp()读入CmdUtilArray,调用对应的方法。其中Adventurer管理Food、Bottle和Equipment(此处的Bottle和Equipment指代所有类型的药水瓶和所有类型的装备);FightLog存有总日志,含有解析日志的方法。
功能联系图示
-
类之间的关系:作为价值体,Adventurer、Bottle、Equipment和Food接口Commodity。其中,ReinforcedBottle和RecoverBottle继承Bottle,而CritEquipment和EpicEquipment继承Equipment。
类之间的关系图示
迭代中的调整及考虑
起初在Main类中解析输入,直接调用Adventurer和FightLog中的方法,使得Main类行数险些超出60行的限制。
在第五次作业和课上理论中,学习到了顶层调用的方式,故设置了MyScanner类和Manager类。
这样做的好处是:轻松达到方法行数要求,且架构更加“高内聚、低耦合”。顺便带来了JUnit测试覆盖率的提升。故而在接下来的增量开发中,我将这种思想也应用到复杂度高的方法中,将方法合理拆解成几个子方法。
在学习了课程组发布的优秀代码之后,我认为我的Adventurer类还有改进的空间:可以将Bag分出来作一个类,降低Adventurer的耦合度。
二、使用JUnit的心得与体会
可以构造一个pay-test测试整个工程的覆盖率,快速得到全面的覆盖率。
在提升覆盖率时:我提高了构造数据的能力,要合理并且全面地考虑到所有可能的分支,在构造数据这方面我不得不花费很大心力,也算是变相地强行训练了。
JUnit提供了单独测试特定方法的机会,并提供清晰的输出和判断,这对debug有很大的帮助。我也曾经在测试分支的时候意外发现了样例没有测到的Bug,或者发现了冗余无用的代码。
总而言之,使用JUnit,对我的思维能力和工程设计能力都产生了积极影响。
三、本学期学习oopre的心得体会
起初我像翻译C语言程序一样进行作业的架构,面向过程编程。渐渐的,在老师的引导下,我逐渐认识到对象在编程中的重要性。课程全程反复强调“高内聚、低耦合”和“封装”的概念。共性行为、共同属性等等任何有内在联系的东西,我们都可以尝试将其抽象并封装成一个对象,最后从顶层调用这些独立的对象,形成对象之间的联系。
当做好了很好的封装之后,对特定对象的改动就显得轻松很多,因为它和其他对象的耦合度很低,因此影响也很小。反之,无论是修改还是测试,都会很困难。我在一次又一次的迭代开发中,深有体会。
此外,我也深刻地认识到了代码风格的重要性。
以上,内聚封装和代码风格是我学习过程中最深刻的两点体会,在其他课程的编程中我也会下意识地回顾oopre的要求,并以此为标准对自己的代码做出调整。
四、对oopre课程的简单建议
希望课程组能够提供一些优秀的代码样例供我们学习!考虑到作业独立性,可以是和作业内容没有关联的优秀代码架构,一方面我们能够有一个改进的目标和方向,另一方面也减少一些重构的可能性。因为重构耗时过大,若再没有一个合适的方向的话,在课业繁重的时候重构得远小于失。