面向对象第四单元博客&课程总结——终究还是没能学会如何测试
一、本单元架构设计
由于本单元是迭代开发，所以后两次的作业都受前一次作业的影响。
类图&相关分析
第13次
第14次
第15次
由于三单元作业以来对于自己构建数据点和发现自身BUG还是没有自己明确的有效方法，本单元作业的成绩都比较不理想。新作业的构建十分依赖对于上一次作业的BUG修复后的版本，为了避免修改产生新的BUG，对于每次新的需求，我尽量采取完全去耦的增量开发。即通过新增类或方法实现新需求，而完全不修改上一代的代码。这样的好处是减少了BUG的复现，而缺点是由于之前的设计可能没有足够的预见性，拓展性不够好会带来重复的计算。但是总体架构还算清晰，大量采用了单例模式、工厂模式，使拓展性还算好，也使得在BUG修复与增量开发时较为轻松。
类内部数据处理
个人在类内部对于数据的处理基本采用在构造期间调用初始化方法来实现对类内部属性的设置，在查询时直接从类的内部读取数据，而不用在线计算。对于有些功能相近的接口可以尽可能的减少无效的计算，减少处理的复杂度。
二、架构设计的演进
个人并没有感受的自己的总体设计架构有非常大的不同，从第一单元的第三次作业以来，本人的总体设计架构就没有太大差别：需求->抽象数据结构->按照功能的耦合性构造不同的类->按照功能进行方法的构造。但得益于CheckStyle的规范，对于细节上方法的长度的限制，让我对于功能划分有了更明确的标准。
第三次作业类图
第七次作业类图
第三单元由于JML的类规划基本固定故不再展示
三、测试方法的演进
说来惭愧，整个OO课程本人只在第一单元、第二单元、第四单元最后一次作业 自己手动构造了不少测试样例并检查出了BUG。对于数据的构造，基本停留在手动构造边界数据，脚本生成完全随机数据两种方式。而正确性的检验几乎完全依赖于和同学对拍检查。而由于脚本写的比较差，加上正确性检验比较麻烦，在每次作业都多少有错误数据。下一步还是要增强自己进行单元测试的能力。
四、课程收获
经过四个单元作业的洗礼，感觉自己的针对已知数据的BUG修复、对于复杂需求的解读能力、较好维护的代码的构建能力都有所提升。但还是对于测试数据的构建和隐性BUG的发掘能力十分缺乏。
五、课程建议
-
-
希望能公布实验结果，毕竟知道自己对不对才能改进
-
对于描述容易出分歧的需求给出边界情况样例和样例说明
