面向对象程序设计第四单元作业总结
面向对象程序设计第四单元作业总结
一、第四单元作业架构设计
本次作业需要分析三类UML图，分别是类图，顺序图以及状态图，并在MyImplementation类中实现所有接口需要的方法。为了不超过Checkstyle限制的最大行数，我将解析三种UML图的任务细分。MyClassModeParser解析类图，MyStateChartParser解析状态图，MyCollaborationParser解析顺序图，而MyImplementation中只需要为三个解析器按照层次顺序输入对应的图内元素，并从解析器中获得对应方法的结果。三种图的解析器结构如下：
类图解析器
顺序图解析器
状态图解析器
在制作各个图的解析器时，我尽可能的将图中各个元素的层次关系还原。例如在类图中，MyClass类表示图中的一个类。类具有属性和方法，因此在类中有MyAttribute以及MyOperation的容器，同时一个类还是ReferenceType，可能被作为属性和参数，因此MyClass还实现了MyReference接口。通过关系的还原，在对指定元素进行查询时，只需要调用元素内部的方法或属性就可以实现（因为元素类已经构建起了关系）。而分析器的任务就是记录所有元素，完成统计性指令：例如类的总数，状态总数等等；在进行查询操作和检查操作时调用对象方法并汇总结果，最后返回给MyImplementation。
二、架构设计思维及OO方法理解的演进
-
第一单元的任务是实现多项式的展开。这项任务本身就具有层次化和面向对象的特征。通过设计因子、项、表达式的类存储各自信息，实现因子、表达式间的乘法，项之间的加法，将这个复杂的任务简化为将多项式拆分成因子，利用因子构建项，再同过项构建表达式的过程。我在这次作业中深刻体会到了面向对象思想的优势。
-
第二单元的电梯作业则让我体会到了设计一个合理架构的优势。在三次作业中，我一直沿用了：输入请求->请求分配给电梯->电梯根据请求运行的处理思路。后两次作业中，根据请求分配的部分产生了较大的变化，我将请求分配给电梯细化为：请求按楼座（楼层）分配->楼层（楼座）内分配电梯，剩余两部分的架构没有发生变化，这也使得我在第一次作业中写的大部分代码可以一直沿用到第三次作业，避免了重构。
-
第三单元的社交关系系统和第四单元的UML解析器比较类似。都是通过设计不同类，记录元素的属性并描述关系构建起一个关系网，并从中获取信息。在设计过程中，我进一步加深了对面向对象思维的认识：每个对象都有自己的属性，属性不仅可以描述自身特征，也可以记录与其他对象的关系。方法则是一个对象为其他对象提供的了解自身特征、使用自身能力的窗口，方法的设计应该满足对象能够提供的所有功能，但也不能完全暴露它的属性。
三、测试理解与实践的演进
- 第一二单元由于完成作业占用了较多的时间，测试通过手动构造数据实现。通过构造部分边界数据和极端数据能够发现程序存在部分的bug，但由于覆盖性差，还是难免出现在强测和互测中被hack的情况。
- 第三单元我使用了Junit对程序进行测试。通过Junit，我能够对程序的每一个方法进行测试。针对方法的测试相比整个程序的测试更容易覆盖到所有情况，也能够准确定位bug出现的位置。因此这个单元我只因为超时被hack了一次。
- 第四单元我通过手动构造UML图进行测试。但手动构造依然存在覆盖性差的问题，一些较为复杂的方法在强测还是出现了bug。
四、课程收获
在一学期的OO课程中，我学习到了面向对象这种解决问题的思路，并通过实践体会到了架构设计的优势。同时，运用在课程中讲授的设计模式、单元测试方法，规范代码风格也让我的代码编写水平有所提高。
除了知识方面的提高外，OO课还锻炼了我的阅读理解能力，总结概括能力，语言表达能力，团队协作能力，面对困难时的应对能力等等。可以说在OO课上，我得到了全面的提高。
五、改进建议
- 个人感觉在各个单元三次作业的难度不太平均。比如说第一单元的第一次作业和第二次作业难度较高，第二单元的第二次作业较高。并且每个单元刚开始的上手难度都比较高。希望能够平均一下各次作业的难度，降低一些上手的难度（可以适当增加预习内容）。
- 希望在课程的评论区中增加一个消息汇总的平台，将同学们在微信群中有价值的讨论内容和询问的相关问题也上传到评论区，或者将评论区中已经出现的提问汇总发到微信群中，避免多次询问同样的问题。
- 希望能够适当缩小互测的规模。面对两三个同学的代码时，可能更有积极性去仔细阅读每个同学的代码，并针对代码中的问题进行测试。
