OO第四单元总结

OO第四单元总结

1. Uml两次作业的架构分析

• 第一次Uml作业

  • 第一次作业类图

  • 第一次作业的架构分析

    ​ 正如类图中所示，第一次Uml作业的需求并不多，只是设计到类图的查询。

    ​ 在设计的时候构建ClassContents类用来存储每个类对应的所有相关的内容。InterfaceContents类中存储的是接口相关的内容，由于接口在作业中只是涉及到继承关系，所以InterfaceContents中主要就是接口的父类的相关信息。

    ​ 在完成作业的过程中，由于存在对于操作(UmlOperation)的类型和包含参数的需求，因此新增加了OperationType类，即UmlOperation的Contents类。包含操作包含的参数以及操作的返回类型。

    ​ 在第一次作业中，自己重写的UmlInteraction类再本次作业中相当于一个数据管理器，不仅提供查询的接口，还包含着初始化数据和对数据处理的函数，没有很好的解耦。也说明本次作业的架构不好。

  • 第一次作业的难点与处理方法

    ​ 本次作业关键难度在于数据处理。由于数据量比较大，并且要按不同的类型归类以提供快速查询功能，因此实现的过程中需要繁杂的数据结构作为支撑。在实现功能的过程中，我在本次作业中，根据需求对于每个元素的每一种查询方法都构建了相应的数据结构。查询的数据结构都采用HashMap实现。

    对于实现过程中的子类继承带来的属性、关联和接口实现的增加，采用的方式是：

    1. 对所有interface继承关系，使用Dfs的方法，把一个interface的所有可达父类都添加在该interface对应的Contents中；
    2. 完善类的实现关系，在该过程中，把类实现的接口的所有可达父类都添加在该类的实现接口中；
    3. 对于类的继承关系，采用Dfs，在过程中把父类的相关要添加的元素加入到子类。
    4. 由于作业中的时间限制，程序中的Dfs的复杂度均保持O(N)，即保证每个节点在第一次访问过并为其更新包含的数据之后不再访问该节点。

• 第二次Uml作业

  • 第二次作业的类图如下：

  • 第二次作业的架构分析

    ​ 第二次作业首先在第一次作业的基础上把数据的管理器分离出来。

    ​ 独立出来InitData、FullFillData和UmlDataManager类分别用来初始化各个数据结、完善各个数据结构中的内容和管理各个数据结构并满足对于数据的规则检查和查询需求。

    ​ 再者对于本次作业中新增加的状态图和顺序图，增加对应的Contents类管理其包含的数据。对于特殊的状态图中的每个状态，因为要存储每个状态对应的后续状态信息，所以对应增加了每个状态的Contents类。

    ​ 本次作业的结构基本保证了每个类各司其职，耦合性降低。上层类只需要调用数据管理器接口，而数据管理器管理每个数据对应的Contents类即可。

  • 第二次作业的难点和处理方法

    ​ 由于是在上次作业的基础上改进，在数据管理部分并没有增加什么难度。本次作业中的几个图的处理难度相对更大：

    1. 状态转换图各个状态组成的图的处理。由于可能出现联通分量，在用Dfs的时候就不能保证每个节点访问一次，否则后继节点可能访问过但是数据并没有完善，带来时间的消耗。
    2. 循环继承检查也是同样的问题。本次作业中采用targan算法寻找强联通分量的方法解决该问题。

2. 历次作业的架构设计和方法理解演进

​ 回顾自己的作业历程，从第一次作业的完全的面向过程编程，逐渐向面向对象的思想靠拢。

​ 第一单元中面向过程的编程方式，从第一次到第二次作业就让我感受到了重构火葬场的魔鬼程度。因此自己也认识到面向对象编程才是完成作业的正道。

​ 在完成第二单元的时候，经历过第一单元的重构爆肝，第二单元从一开始就尝试着构建更加清晰地架构来提高程序的可扩展性，也收到了一定的效果。由于第二次作业构建了二层调度器，从第二次电梯到第三次电梯作业的重构部分并没有很大，也有更多的精力放到多线程问题方面。

​ 第三单元，有了官方的接口完成自己的容器的时候已经有了一定的架构能力。第二次Jml作业中把图的管理和图的算法实现分开，第三次作业也能够用更少的时间去重构一些数据管理，可以更多时间放在图算法的实现和性能提高。

​ 到第四单元由于需求并不难完成，（有些放飞自我）架构设计没有下很大的功夫，数据的管理花了很多的时间。

​ 总体来看，作业的架构在逐渐的向好的方面发展。

3. 历次作业中测试理解与演进

​ 关于测试，自己做的并不好，也是为什么会出现一次作业因为一个bug导致强测成渣。

​ 最开始，由于并不会使用脚本等等构建数据构造器和“对拍器”，更多的是进行人工读代码肉眼debug，在发现了这样不出第一单元自己就会累死之后，开始主动了解测试方法。

​ 在第一单元的第三次作业，学会了利用脚本语言，自动构造测试集并且自动计算和比对方法。算是从原始人走上了测试进化之路。

​ 在第一单元的优秀作业中，看到了同学使用的JUnit测试方法，在第二单元中也进行了初步的使用，用来验证一个方法基本正确性。但是更多的还是利用自动测试集进行黑盒的大面积测试。

​ 在第三单元中，了解到了契约式编程和Jml的相关测试方法，学会了更加有针对性和更加全面且省力的测试方法，进一步的了解了JUnit。

​ 而对于测试方法的不断学习也和自己对于面向对象编程的学习相辅相成。在逐步深入的理解面向对象的时候，有了更好的架构之后测试也会更加方便并且可靠性更高。

4. 课程收获

​ 通过一个学期该课程的学习，虽然并不敢说自己真正的学会了面向对象编程的思想，因为还有很多的更深层的内容有待学习。但是，在课程中让自己从最开始的拿到一个需求或者题目就上手从头到尾顺着编程，到逐渐养成了先规划程序的结构，思考如何构建工程才能降低各个模块的耦合，做到分工明确，也是为自己debug减小难度，之后再着手编写程序。

​ 第一单元求导，也是对面向对象的初步理解。到第一单元的第三次作业，学会使用继承和接口之后，切实感受到了面向对象的一种魅力，和面向对象编程中一个明晰清爽的构架是多么的重要。

​ 第二单元的电梯，初步感受多线程编程。处理线程交互和死锁问题等等更考验着工程能力和架构的设计。

​ 第三单元Jml，是对契约式编程的初步了解。在这一个单元中，也完成了自己感觉最符合面向对象思想的作业。

​ 第四单元Uml，是一种利用类图等等图形理解程序运作机制的工具。这也是工程开发中重要的工具，也对更深层次的理解一个工程的架构和改善工程架构有很大的帮助。

​ 总之，这一个学期的面向对象的学习的结束不是面向对象编程的结束，恰恰是为我们打开面向对象这扇门，更多的内容还需要我们自己更深入的学习。

5. 意见建议

​ 一个学期该课程的学习体验整体较好。并没有出现流传的一些怨气深重，毫无收获的感觉，反而感觉该课程挺充实。老师和助教也足够的负责和辛苦。

​ 也有一些小小的建议：

1. 在第一单元中希望以后可以再做出一些修改，避免成为面向WrongFormat编程
2. 作业时间线的问题：最初对于既定的时间线总会出现延期等等问题，希望可以更加严格遵守既定规则，共同维护。
3. 也大概是因为本学期是第一次如此改革，作业的一些需求方面会出现纰漏，导致延期等等问题。
4. 对于上机，希望改一下机制，而不是上午刚讲过下午上机就要用，会感觉很匆忙。

希望课程可以越来越好！