OOPre_hw8_心得体会

[24371362-乔鲮旭]

OOPre_hw8

1.架构和调整

整体架构如上，每个类按照作业要求实现基本功能，具有其基本属性，其中在Adventurer类下的Bottle和Equipment容器是未在背包中的，Adventurer类下的Bag类下的Bottle和Equipment容器是在背包中的，属性均已private并设计应有的访问方法

关于迭代：

（1）关于子类：

在第二次迭代过程中，我设计了若干子类，譬如Bottle的子类HpBottle,AttackBottle,ManaBottle,DefBottle，但随后发现我实际上没有怎么实际的体会到这样的好处），究其原因，我认为在这个系列的迭代任务中，设计type就可以很好的区分不同类别，设计很多的子类除了可以减少某类的长度，避免在checkstyle中丢分没有十分特别的用途。

（2）关于接口：

本人在第三次迭代的过程中删除了全部的接口，在后续的设计中也没有使用过接口

关于接口这里，我在第二次迭代中使用了他，因为作业要求，后续发现没什么用（未经）因为本身完全不简化代码反而更麻烦了（尤其Junit中），在我的理解中接口似乎是一个“最大公约数”，限制了实现接口的类的扩展，但是似乎在作业中就是需要很多扩展，即接口的作用不太适合我们的冒险小游戏，因此本人后续删除了接口并不再使用。

（3）关于ArrayList，HashMap：

在作业中多次涉及了这个部分，HashMap在我看来就是进阶版的ArrayList（仅在实现某些功能上，并不是说定义上），此处我并没有优化和重构，主要是作业也没要求时间复杂度和性能。

此处我觉得最重要的记得某一个地方的容器是干什么用的，不要前后矛盾（血泪教训）。

此外，关于ArrayList，删除时要小心没有及时跳出循环的话，循环是不是会产生bug。

（4）关于Bottle,Spell,Equipment细节的实现：

按照要求来，逐字阅读，即可实现，唯一的问题是先想想有什么共性的可以单独写一个方法，避免方法过长checkstyle不通过。

（5）雇佣关系的实现：

我是采用维护ArrayList的方式实现的，这个注意冒险者死亡的时候更新容器要全面即可，确定盟友和上下级的时候采取遍历的方式

（6）关于工厂模式：

接口进阶版

其实在作业中，很多东西差异很大，并不适合大范围的用工厂模式，仅在小范围使用不如直接new一个对象

（7）重构：

我并没有怎么重构，反而是在屎山上微调，主要的考虑是不要新造出来的架构还过不了之前的强测，所以调整是，除了删除我认为并不必要的接口，工厂模式等，我都是微调逻辑完成的。

2.JUnit的心得

以下均为个人见解

（1）优点：JUnit可以很好的解决深浅拷贝所造成的低级bug

（2）缺点：对于OOPre课程的迭代作业来说，开发量并不是太大，记住一些细节并不难，设置大量的JUnit测试的代码量反而比完成迭代任务量更大了，而且对于测试覆盖率的要求，我认为给一些复杂的方法设计测试没有问题，简单的方法仅看是否拷贝成功即可，这对于debug大有裨益，但是却无法达到覆盖率的要求

（3）无法满足又真正会造成bug的地方：读不懂题，后面忘记了前面的架构导致设计的前后不一致，方法传的参数的含义不同但是根本不记得另一处的具体要求是什么（）

3.学习OOPre的心得体会

首先这是一门很有意思的课程。

我认为我主要在以下方面得到了提升：

（1）架构能力

还记得我在第二次迭代的时候就觉得这个情景很复杂而去问了某位助教，在助教的建议下我自顶向下设计架构，在迭代中（客观上讲对于初学者码量不能说很大也不算小吧，对吧）提升了一点点分析架构能力。

（2）debug能力

其实我觉得过强测最重要的是会debug，对于中测的bug，JUnit是一个很好的工具，同时对数据全面性的思考也很重要。而在强测中，我认为最重要的咬文嚼字分析指导书：

首先是理解错误，这个是导致我在hw6强测中错了一个点的问题，当时我错误的理解了aid的意思，我以为use是要先aid然后改变了HitPoint再输出冒险者的情况

其次是我认为最重要的在写之前先想想可能的bug，比如冒险者死亡的话应该是怎样的，可以避免一些弱智错误。

最后陪一张分析图

这个东西让我先想清楚了怎么设计然后可能的bug是什么，要注意什么，避免因为写到后面脑子一热犯糊涂导致的无畏错误。

（3）从面向过程编程过渡到面向对象编程

其实本人的屎山还是主要是面向过程的设计，因为这个作业还是以判断为主，不过以此作为过渡也是一个不错的体验，

4.对OOPre的建议

（1）增强对于git和工具链配置的讲解（不然到后面实际上大部分人还是没有掌握）

（2）直接引入互测（刀人什么的，最好玩了，一定能增加同学们的积极性）