OOPre结课总结

1.架构设计、架构调整及考虑

架构设计：

main类作为函数入口，负责接收控制台输入的指令，我采取的是接收到一条指令就根据指令类型进行相对应的操作，为了实现课上所讲的高内聚，低耦合，故我定义了Service类负责进行指令的具体实现操作，main方法里就负责传参给Service类让它去寻找该执行什么指令的操作。这是我的顶层输入处理逻辑。

然后就是为什么要创建这些类，类里的属性方法应该尽可能相近，比如Bottle、Equipment、Food有各自的属性，与其他类的性质不近似，所以就要新建一个类。据此，我单独创建了一个Fightlog类，负责战斗日志的处理。还创建了一个Shop类，负责购买物品。

我的代码重点几乎都在adventurer这个类里面，我是考虑到adventurer几乎是大多数指令的直接受影响者，故adventurer里面有许多的方法，全都是依据指令的要求创建，当外部读入一个指令的时候，先进入Service类，然后Service调用具体的adventurer对象进行他本身的操作，我觉得是很符合逻辑的。

综上，我的代码架构是根据它是什么、它应该具有什么的逻辑建立的。

架构调整及考虑：

我的代码在第三次迭代开发的时候进行了一次比较大规模的重构，主要是因为之前没有注意到main方法不能超过60行，然后堆积了大量的指令操作在main里，经过重构后新增了Service类，这样一来，对于新增的迭代开发就方便了许多，后续的重构规模量也不大，大部分都是直接新增即可，而且我在前期的开发中就想着下一次的操作要尽量轻松一点，所以说做了不少预留空间，比如这次作业的删除食物，第一次作业的时候就考虑到了背包的问题，写了从背包中移除，所以这次做作业的时间不多，因为前期已经做好了预留的准备。

我感觉之后的开发也是一样的，不要拘泥于眼前短暂的任务，为了完成当前任务去定义某个方法或者容器啥的，因为可能下一次的新增内容或者改动就会导致你这次写的东西不适用，到时候改动量就会很大，花的时间也许会比一开始想好之后可能会怎么发展再下手时间多，下学期的oo课争取自己也多注意这一点。

2.使用JUnit的心得体会

每次作业写到最后，就要感慨又要开始写Junit了，我觉得这或许是OOPre最痛苦的一集。

但是通过使用Junit，也有收获。首先，它实现了system.out.println出来值自己比较的自动化，通过assertequal函数可以交给系统自动判断是否为对的。这就避免了我们可能在某些地方打错而导致了我们发生代码错误。但是我的Junit样例构造还不够全面，所以在最后一次作业的强测中犯了错误。

除此之外，我深刻认识到评测机的重要性，因为JUnit还是靠自己编造样例来测试，所以覆盖上难免有不足之处，学习搭建评测机，为下个学期的oo正课做准备，我觉得这很有必要。

3.学习OOPre的心得体会

第一次作业的时候，我是非常不习惯的，因为习惯了C的面向过程性，总觉得java这种方式太不符合我之前的思维逻辑习惯了。但经过几次作业后，我现在已经深刻感受到了面向对象编程的好处了，其中我感触最深的就是封装这个特性，它把我们写好的东西作为一个黑盒，使用的人不知道里面的架构具体是什么，只需要知道它露出来的接口可以做什么，接到哪里可以实现我想要的东西就行了，这非常符合日常生活中我们使用电器等物品的行为，使用者不关心内部是如何构造的，他只需要知道怎么做就可以实现想做的事情。

然后感觉学oopre能学到一些处理代码的细节吧，比如代码框架的搭构，具体方法的实现，高内聚低耦合的要求啥的，确实在自己的代码写的程序中起了不少指导作用。框架搭好了，迭代开发的重构就不需要变动太大，就会减少很多的工程量，这是今后的oo课程需要注意的。

还有就是自我总结的debug方法：检查题目要求——检查代码逻辑——检查函数调用的名称以及传参的名称。

这个调用名称和传参名称带来的伤害太大了，我和我的一些同学都在此上犯了错误，浪费了非常多的时间，如：

 

 

检查了很多遍代码逻辑都觉得没啥问题最终在一条一条数据的寻找中查出了这个问题，我想可能不仅仅是我自己，也许也有不少人也会犯这种错误，希望这个debug方法能帮助到你我吧。有时候觉得代码逻辑没问题了，就看看自己具体怎么写的吧，或许会帮助你发现自己一些愚蠢的错误。

4.对OOPre课程的简单建议

建议在第一节课的时候讲一点基础的java语法知识，稍微具体一点，别全部都是抽象的概念，我记得我第一节课的时候就对这些抽象的概念深感痛苦，因为甚至还不知道一个类只能有一个public class...。

除此之外，我个人感觉oopre挺不错的，作业内容还挺有趣的，虽然一开始git的环境配置很痛苦，但配好了确实还是能感受到有在往专业性方向走，在后来的学习中也确实感受到了代码管理的重要，希望oopre越做越好。