第四单元总结博客

1.第四单元作业的架构设计

1.1 第一次作业

第一次作业刚开始看到前人的经验分享建树，查找方法直接对树操作。但我根据自己对类图的理解，选择了使用HashMap。新建类Item，用来存储Class，Operation，Interface这些还有下属成员的元素。Item中有不同的类型为HashMap的成员变量。这些HashMap用来存储Class下的属性、方法、子类、关联、实现的接口等相关元素；还可以存储Operation下的参数；Interface的属性，各个继承接口等等。除此之外Item还存储了Class，Operation，Interface本身、其父类、parentid等等。不具有的成员，比如Operation不具有子类，HashMap初始化为empty，其他类型初始化为null。

这种架构方法运用了很多HashMap，而且各种元素互相嵌套，理清思路比较麻烦，而且由于各种关系之间的构建需要寻找相应的成员，容易出现null报错的情况。优点是把所有元素的关系理清之后，查询操作的思路比较清晰。

采用这种方法的思路是，把一个个体和所有与它有关系的信息全都集合在一起，有点受到第三单元作业关系网的影响。

1.2 第二次作业

第二次作业新加了顺序图和状态图，思路与第一次大致相同。对于顺序图，新建类Sequ用来存储Interaction和Lifeline。Sequ中的HashMap用来记录Interaction中的各个Lifeline，记录Lifeline中的传入和传出消息。对于状态图，新建类Union用来存储State Machine和State。Union中的HashMap用来记录Machine中的State，记录State的移入和移出。

对于顺序图的起点和终点，会出现null的问题。

此外，第二次作业还采用了工厂模式。由于第一次作业直接在查询函数处进行数据处理，导致结构混乱。第二次作业新建工厂模式，将处理后的数据HashMap提供给查询函数，查询函数只负责查询功能的实现。在工厂中，先将UmlElement处理成相应的Item，Sequ，Union类，或者保持原来的UmlElement类不变，进行初步分类。接着再构建它们之间的联系。

1.3 第三次作业

第三次作业大的架构没有变化，主要是增加了一个新类，传入工厂的数据，进行一致性检验的实现。同时，还根据需要对原有的Item，Sequ，Union类稍微进行了修改。比如在Union中加入初始状态和结束状态的成员变量，简化check操作。

2.架构设计及OO方法理解的演进

2.1 架构设计

第一单元基本没有架构设计，三次作业就是一次一重构。第一次作业只有多项式，第二次作业添加了三角函数，第三次作业才用接口、通过树和递归实现求导。第二单元与第一单元相比架构方面没有那么狼狈，基本都是可以沿用上一次作业的架构。第一次作业是单部电梯的调度策略，第二三次作业只需要在原来电梯的基础上进行修改。第二单元的作业主要难在调度算法的设计，第一次作业的捎带策略可以沿用到后两次，后两次只需要在不同电梯间修改调度策略，每部电梯自身的调度策略不用大量修改。第三单元作业完全按照JML的架构。第四单元架构改动不大，但还是有修改。第一次作业的架构虽然数据结构组织的思路比较清晰，但是各个功能模块没有分开。第二三次作业沿用之前的数据结构，将功能模块重构、分散开。

刚开始写OO的时候没有太清晰的架构设计的概念，第二单元的作业有了第一单元的教训，开始留意以后可能增加什么功能。第三单元因为觉得JML给出的结构满足了作业的需求，也没有自己设计。第四单元在一开始就已经考虑到要为以后做准备。总的来说随着单元的推进，开始渐渐认识到架构设计的重要性。一个好的架构设计不仅可以一定程度上把设计和实现分离，还可以帮助检验程序的可靠性与正确性。

2.2 OO方法

第一单元作业中，前两次作业还是面向过程的思想比较重，到了第三次作业基本上是重新写了一份面向对象的代码。面向对象的思想可以继承类、实现接口，在处理表达式方面非常灵活，可以用父类或者接口类型统一引用。第二单元作业的面向对象思路就很清晰了，电梯、调度、接受数据，是三个类，每个类有自己支持的操作。在线程安全方面，面向对象的思想提供了易于理解的方法，只要每个类保证自己支持的操作是线程安全的，其他类只能通过该类的操作处理该类的数据，就能保证所有的交互操作是线程安全的。第三单元的作业中，体现了面向对象思想中不同类之间的关联依赖等复杂关系如何处理，在类的成员中存储相应类的引用。第四单元的作业也主要使用了与第三单元相同的引用方法。

面向对象的方法其实在C语言中的struct就有体现。一个类可以分为三部分：成员属性、操作方法和构造方法，类中的属性由类自身定义的操作来处理，把每一个类封装起来，外部只需要知道他的使用方法，这也是第三单元的重点之一。类的继承、接口的继承、接口的实现，也为面向对象方法提供了统一引用方面的便利。

3.测试理解与实践的演进

第一单元的测试我没有搭建自动测试的程序，主要还是手动测试。测试样例主要是边界数据，但是括号嵌套括号看起来很费劲。第二单元的测试关于如何定时输入数据我苦恼了一阵，最后在讨论区得到启发写了一个新线程专门用来定时输入。第三单元接触了JML和Junit开始尝试单元测试。但是我自己进行的课下测试很难保证性能要求。第四单元主要是用StarUML自己画图作为输入，进行程序测试。通过这几个单元我逐渐接触到更加方便、可靠的测试方法，程序的测试除了使用大量的测试样例进行检测，还可以在设计层面进行验证。OO测试采用中测、强测、互测，能对程序的正确性和性能进行很好的检测。

4.课程收获

最直观的收获就是初步掌握了JAVA编程和提高了自己的心理素质。通过对OO课程的学习，接触了一种新的编程思维，以类为单位进行抽象、分层、程序设计，与过去的面向过程思维不同。体会到了容器对程序性能的巨大影响，再编程时更加注重程序的性能和数据的存储与组织。学习了从更高的角度去看待程序的实现与测试，先进行架构设计、再进行实现。了解到了更加贴近实际使用的一些工程方法与设计思想、设计模式。接触了线程安全的概念，打开了新世界的大门。见识到了大佬的经验分享。

5.改进建议

1)第三单元第二三次作业指导书补充：容器对程序性能的影响，ArrayList与HashMap有很大差距，慎重选择容器

2)第四单元第三次作业指导书补充细节，避免歧义

3)提前发布实验PPT，实验内容对完成作业有帮助

6.线上学习OO课程的体会

这学期因为特殊原因OO课程是在线上进行学习的，与之前线下学习的课程有很多不同。首先就是课程安排，中测截至时间、互测时间、bug修复时间、上机考试与研讨课交替，就是因为OO课我才能记住，这周是单周还是双周，今天是周几。因为在家里，所以和同学之间交流思路与想法有点不方便。不过线上研讨课还是通过腾讯会议得以正常进行，线上会议的模型也曾在OO课上作为例子来讲解。课后测验和课堂讨论题也让老师和助教费心了。OO这门课程的线上学习能够实现是很多人努力的结果，夸张点说天时地利人和，只要真心想学好、办好一门课程，就算没有条件也能创造条件，感谢老师和助教的付出，为我们准备了一次难忘的线上OO课程。还有每单元最后的问卷实在是太皮了。