oopre课程总结反思

最终架构设计

价值体

这一部分类所实例化的对象是完成需求需要处理的重头戏。

Bottle类、Food类、Equipment类的属性均只是设有其基本属性及方法。Adventurer类除基础属性之外，为满足需求，还包括了与前三者相关的属性（一个名为xx的HashMap表示所拥有的及一个名为xxBackpack的HashMap表示所携带的 xx为bottle、food、equipment），以及名为laborers的HashMap表示所雇佣的冒险者。

待改进之处：学习优秀代码之后发现，确实把与Backpack相关的属性方法从Adventurer类中抽离出来会更好一些。一方面Adventurer类中方法会大幅减少，功能形式会更接近其他价值体，另一方面代码总体架构也会更为清晰明了。

非价值体

这一部分类所实例化的对象更多的是为了辅助价值体实现需求。

FightLog类记录每条战斗日志，FightMode类执行战斗日志，Input类中logGeneral与modeGeneral用来分别储存所有的前两者的记录。Shop类完成所有的冒险者与商店之间的交互。

待改进之处：编写之时只是为了方便将logGeneral、modeGeneral、teamById、teamByName放在Main函数并传入Input类中作为其属性，但并没有实际的含义。在优秀代码中看到了一份应用单例模式构造一个新的World类的代码，我的这些确实作为只能实例化一次的游戏世界的属性会更为合理更有意义一些。

历次迭代的架构调整

hw2->hw3：将Main函数中的对不同指令的处理抽离到一个Input类中，让Main函数更为精简

hw3->hw4：增加FightLog类和FightMode类，前者用来记录战斗日志，后者用来执行日志。同时在Main函数中创建logGeneral、modeGeneral记录前两者，便于遍历

hw4->hw6：实现Bottle类和Equipment类的继承，及Community接口

hw6->hw7：在Shop类中实现单例模式

关于Junit

值得肯定的是，编写的Junit确实帮助我找到了不少的bug，得益于它更加独立分块的单元测试和自行构造的十分简单的数据，往往十分有助于发现问题所在。

但是，更多的Junit的编写是为了通过评测机的要求，而且一般Junit的编写是一个十分让人破防的事情👉👈。并且我从控制台输入的指令写到Junit里面真的实现很不优雅(敲打)

oopre学习心得体会

第一次接触面向对象编程，我最最最直观的体会主要有以下几点：

1. 它相较于面向过程要求我们有更为清晰的代码结构。从每个类中方法的构造、对实例化对象的管理，到类与类之间的继承、接口的实现，都需要仔细的考量。因而每次完成作业总要呆呆对着电脑想很久...

2. 它要求我们每一次的迭代要“留有余地”。迭代式的作业，除了每次实现需求之外，需要合理地估计需求易变性，尽可能地让后续的操作优雅，否则很快就会迎来代码重构(× 然而，面对特定的实现目的，代码重构有时是不可避免的。适时的代码框架的修改能够改善程序的设计复杂性， 使得代码更容易理解 。

3. 它把代码组织成类和对象的形式，每个类都有自己的属性和方法，使得代码更加模块化和可维护，同时所描述的关系和行为也更为贴近实际问题。

对oopre课程简单建议

总体课程体验还是相当棒的，但是美中不足的一点是个人感觉还没有完全领会到应用设计模式真正的有益之处(很有可能是因为没有完全理解)，或许下次的oopre课程作业可以在这方面有更多的应用，通过实实在在的代码编写领会设计模式。

再次感谢吴际老师和助教老师们帮助Java小白迈出了面向对象的第一步 \庆祝/\庆祝/