OOpre总结

架构分析

功能分析

Main:处理输入

Control:根据命令类型执行不同的命令，存储所有的冒险者、战斗日志（按月）

Adventure:执行冒险者的各种操作，存储雇佣的冒险者、药水瓶、装备、食物、战斗日志（按人）、背包

继承关系

几个特点

1. control中相似操作用选择信号代替，减少代码重复

   具体的，删除、加入、获取名字等方法一样，分别用1、2、3指代药水瓶、装备、食物；价值体接口中的get_value 专门用来返回各个类特有的属性如药水瓶的容量、装备的星级、食物的能量等

2. 除必需遍历输出的战斗日志外，全部采用HashMap、TreeSet，提高效率

3. 输入只在Main中，其他方法传入字符串等参数，方便调试

架构变动

• 最大的架构变动来自于P3到P4，原因是Main类里实在塞不下那么多类型的指令调用（代码风格过不去），因此把指令实现都放在了control类中，此后新增的操作分为switch1、switch2等等，嵌套调用
• 其次要算新增了价值体，继承的使用大大简化了Adventrue类中存储结构的设计
• 最后一个小改动是战斗日志的处理，P6到P7的改动将这个处理更加清晰地分为2个方法

不足分析

• case数太多，寻找更优雅的解决多指令的方式
• 战斗日志的输入解读仍然不尽如人意，代码冗长、不优雅，看上去还是像屎山

Junit的体会

简单评价

个人角度来看，junit侧重于针对每个类或者方法单独测试，然而大部分的bug实际上来自于方法之间的调用、类与类之间的关系等等，因而对某一类、方法的测试可能局限于简单测试功能的完善性，而无法进行完全的测试。但如果通过对不同情况的仔细考虑造出强数据点并在类似顶层类（如control）中进行测试，则既可以测试每一方法、类，又能测试类与类、方法与方法间的调用关系，更加完备。

使用体验

• assert的使用确实可以减少自己一个一个对数据点的烦恼。
• 在每次迭代后，都需要花费很多时间精心设计覆盖率足够高的数据点，看似很不划算，但真的是检验程序的一种绝佳方法（我自己在测试时经常出现程序崩溃的情况，输出错误反而很少。。。），确保提交的程序至少能够成功执行某些情况下的全部指令。

OOpre的体会

面向对象编程

其实从C++和java对比来看更为明显，C++虽然也有类、支持继承、重载等等，但并没有显式的推荐一个类单独写一个文件（自己都快把类当有函数的结构体用了），还是容易造成”一main到底“的情况。而在OOpre中，由于java中的主体是类，真的需要认真考虑每个类到底有什么属性、功能，从而认真设计，相当于迫使程序员面向对象编程。

框架

OOpre中，每次迭代都要根据新增的数据类型与指令要求设计新的存储、调用方法，因而程序的框架就十分重要。另一方面，代码量的显著增加也要求每次设计必须预先规划，而不能边写边想边改。

比如针对冒险者的操作大多根据id进行，因此可以用HashMap进行存储。但后续增加通过名字查询的功能时，又不得不增加一个名字-id的HashMap也是无奈之举。

又如类与类之间的联系、分工也应在开始编写之前考虑清楚，具体框架见前述。

代码风格

统一化的代码风格这一要求其实还是容易理解的，但是还是有一些要求令我在编写时绷不住，只能尽量靠近要求

• 每行不得超过100字符。从前写C时每行很难超过50字符，但由于java中相互调用太多，因此一行中很容易因为各种方法的嵌套调用而超过100字符。（其实也说明代码结构不够简洁）
• 每个方法不得超过60行。这一条与上面一条结合，直接促成了我P3到P4的架构大改。
• 变量命名必须使用小驼峰。主要是和我之前已经习惯的下划线的命名方式冲突，改起来比较费劲。

课程建议

1. 第一次作业相关环境的配置、java语法的介绍太少太乱，太难上手，而且各种说明放在一个文件夹里，每个说明还只解决半个问题。比如git和idea的下载完全可以分成两个文件，git的下载、配置、使用说明等等和gitlab的配置完全可以放在一起，一步到位。又比如《公测文档》、《建议得分说明》、《其他说明》互有重叠，想查找相关说明时无法根据文件名查找，还得逐一查看。
2. 既然没有互测，可不可以把强测结果开放时间、bug修复时间提前？（进一步的，考虑提前开放下一次作业？）