目录

作业最终的架构设计, 在迭代中的架构调整及考虑

最终的架构设计

Main类

Main类作为顶层类，只读取指令的个数，具体每一个指令的读取交由管理类Manage处理

Manage类

Manage类只读取指令操作符，并将指令操作符和指令一一对应进入具体实现他们的Action类

Action类

Action类中存放着23个指令的操作内容，实现流程是先将操作符后的内容传入Parse类解析返回一个匹配器mather，根据匹配器的结果得到指令的各个参数，再进行处理

Parse类

Parse类中存放对23条指令的解析模式，通过正则表达式的方式为Action类返回需要的匹配器mather

Log类

日志Log类的主要成员变量是日期和一个字符串数组，用来记录在某个日期内发生的所有日志，还有一个静态哈希表用以记录所有的Log类

Commodity接口

价值体Commodity接口由冒险者类Adventurer，瓶子类Bottle，装备类Equipment，食物类Food实现，共同持有查询价值的方法

Adventurer类

在冒险者类Adventure中静态的方法和变量有

• 冒险者哈希表adventurers
• 战斗者数列fighters
• 几乎全部方法

其余非静态的变量有

• 冒险者的仓库哈希表bottles, equipments, foods
• 冒险者的背包bag
• 冒险者自身的属性

Bag类

背包Bag类的功能类似冒险者的仓库，同样有仓库哈希表bottles, equipments, foods，只有在Bag类中的物品才能被冒险者使用

Bottle类

瓶子类Bottle有如图三个子类，唯一的区别在于使用时增加体力的算法不同

Equipment类

装备类Equipment有如图三个子类，唯一的区别在于使用时攻击的算法不同

Food类

Food类由于没有子类，因此使用时只有一种方法

Shop类

Shop类管理售卖和购买的所有内容

迭代中的架构调整及考虑

阶段一： 第二次作业~第三次作业

没有专门的解析类，所有的输入读取和内容实现都在main方法中堆积，最后在第三次作业中代码风格检查时发现行数超60行了，虽然缝缝补补过了，但还是在第四次作业中做出了改进

阶段二： 第四次作业

设置了专门的解析类，并且将方法具体内容放在了main方法外，但管理和实现仍放在同一个Action类中，导致代码看起来非常繁琐

阶段三：第六次作业~第七次作业

学习了第五次作业的demo后重构了代码，设置了专门的管理类Manage和实现类Action，后续添加指令变得更简单了

学习了接口后，将所有需要获取价格的对象抽象为价值体，在编写针对价值体的方法时不用为Bottle类，Equipment类等等分别单独编写方法了

使用junit的心得体会

之前对junit一窍不通，甚至好几次因为不会写而没过，在第六次作业的时候学习了setIn大法setIn大法好啊，setIn实际上就相当于自己写了一组测试数据，看看符不符合期望输出就行了，这样写只是因为在保证覆盖率的同时花的时间还少，在代码逻辑较简单时这样做是高效且简单的，但一旦代码逻辑复杂起来，直接人为编写测试数据就无法保证能够覆盖所有分支和方法，要保证每一个方法都得到覆盖，都要单独进行测试，或许在以后代码逻辑复杂起来之后会遇到这样的情况吧

学习oopre的心得体会

首先，从0开始学习java是比较痛苦的，尤其是第一二周，对类，对象，静态，git等等概念生疏导致我花了大量时间查阅包括但不限于csdn、百度上的资料，但是好在idea是一个十分优秀的编辑器，能够解决小白的绝大部分语法错误DEV使用者泪目，同时也为熟练使用者提供了大量方便的功能，因此，在写了一两次作业之后，作业写起来就没那么困难了

其次，本地的充分测试真的十分重要，好几次中测过了强测没过，并且都是十分细小的疏失导致的，都是源于本地测试不充分，过度依赖评测机的后果，因此，课程组教大家使用junit，确实并不是完成课业后的空穴来风，而是保证代码安全性的必要手段

最后，感谢群里积极讨论的同学和助教以及学长学姐提供的博客，为我完成作业提供了大量的帮助setIn大法也是博客里学的，没有大家的帮助我不可能顺利完成oop的七次迭代

我的心得体会就到这里，再见，咱们oo见（刀战下手轻点

对oopre课程的简单建议

1. ddl能不能放在周四晚上啊QAQ