BUAA OO 第四单元总结

Part 1 本单元作业设计

总体来看，本单元作业主要做了两件事：

1. 针对关键的UML类构建对应的adapter。比如针对UMLClass类构建UMLClassAdapter类。
2. 将顺序输入转化为具有一定结构的图。比如状态图的元素是顺序输入的，代码需要将这种顺序输入转化为具有一定结构的图，即状态图。

以下具体分析：

第一次作业

第一次作业只有类图，我针对关键的UML类构建相应的adapter，然后将这些adapter聚合到一个Graph类中。Graph类进行数据解析，并提供类层次的查询。

第一次作业并没有进行很好的设计。一方面，当时对题意理解有一些偏差；另一方面，当时误以为这一单元作业只有两次，对代码可重构性要求并不是很高。

第二次作业

第二次作业增加了时序图和状态图，我也对应地编写了相应的adapter类，然后对这些adapter进行聚合，最后封装到一个包里面。最终我增加了两个包，其余部分没有较大的改动。

到第二次作业的时候，我已经知道本单元有三次作业了，所以在设计上开始注意了。

第三次作业

第三次作业增加了对元素的检查，我为相应的adapter类增加了对应的检查函数，并在聚合类（如Graph类）中整合。

这一单元的作业我个人感觉一个比较遗憾的地方是在第一次作业时并没有进行良好的设计（一方面当时对题意理解有偏差，另一方面当时各种考试比较多）。

Part 2 对架构设计和OO方法的理解

第一单元

关于类和接口，主要有以下几点：

1. 出于程序的需要，我们定义了一个数据结构，为了操作这些数据，我们定义了一些方法。将数据结构和专门用于操作这些数据的方法写在一起，就构成了类。
2. 这些类在现实中有物理含义，所以它们自然有具体化、组成、关联等联系。这和自然语言的语义、人们对事物的认识是一致的。
3. 编写类的目的，是便于人们使用，所以需要隐藏一些不必要的细节，对外提供明确的接口。明确的接口就是一种规格。
4. 类可以实现很多接口，每实现一种接口，就可以供一组特定的用户使用。

关于设计思想，主要有以下几点：

1. 不要依赖于具体。代码不要和具体的东西绑的很紧。如果确实无法避免，那就应该把和具体相关的代码独立出来。比如，从一个字符串，解析其内容，就是一种比较具体的操作，应该独立出来。
2. 对数据的操作不应该干预决策。比如，管理具体数据的类，不应该做具体的化简的操作。

第二单元

第二单元主要是多线程编程，主要理解总结为以下几点：

1. 模式化的设计：比如生产者-消费者模式，包括电梯作业中使用的比较复杂的生产者-消费者模式。这些模式比较实用，在写代码的时候直接使用显然比较方便。
2. 并发编程要尽可能减小线程间交互的面，也就是说，临界区尽可能小，尽可能简单。
3. 线程间分工明确，事先规定好各个进程的分工。

第三单元

第三单元主要是规格化设计，主要理解总结为以下几点：

1. 规格将类之间的分工协作用一种明确的方法表达了出来，这让使用这些类的编程人员能够更好地使用这些类。
2. 契约式的设计可以使多次迭代代码的维护更加轻松，不容易误解之前自己的设计，也不容易把代码改乱。
3. 规格化是建立在编程人员具有较高设计能力的基础上的。如果设计不好，那么写规格反而容易成为一种负担。

第四单元

第四单元主要学习了UML的相关知识。主要理解总结为以下几点：

1. 先画UML图，然后再实现。将设计与实现分离。
2. 一个模块或者部件，对模块间共享数据的影响要尽可能的小。比如，解析类图的函数，不应该影响顺序图或状态图中的元素数据。
3. 模块化设计，各个模块互不影响，这样增加功能的时候整体结构也不会受到太大的冲击。

Part 3 测试

一般而言，课程所设计的作业的测试需要解决两个问题：

• 怎么获得输入数据
• 怎么检测在给定数据输入的情况下，程序运行的正确性

当然，其他项目的测试可能并不简单，有时很难用输入、输出来测试，所以可能需要很广泛地应用单元测试等测试手段。但是，对于课程所涉及的作业，完全可以使用输入-输出测试（因为统一测试就是这样的），所以可能单元测试并不能充分发挥它的作用。

第一单元

第一单元主要是手动构造数据，再进行机器验证。手动构造，主要是枚举有代表性的数据；机器验证，主要是仿照测评机的原理，对输出数据进行验证。

这一单元也使用了单元测试的一些思想，对化简模块、输入模块进行单元测试。

第二单元

这一单元主要通过自动生成输入数据，再用模拟器进行模拟验证。我个人感觉，这一单元的测试可能是这四个单元中做的最完善的，因为电梯作业的验证并不需要依靠外部因素（比如对拍、与其他人交换数据）。

第三单元

这一单元主要是自动构造数据，然后与他人进行对拍来验证。也使用过单元测试，但是感觉效率不高，因为待测代码本身并不是很复杂。

第四单元

这一单元没有做充分的测试，主要是手动构造mdj图，然后与其他同学进行对拍。

Part 4 课程收获

整个课程学下来，总体的收获主要是对面向对象的设计的了解。虽然也没有多少深入的了解，但是也算是入了门。设计思想上的收获，主要在第二部分做了表述。除了思想上的收获，我认为整个课程培养了我的代码实现能力。不仅包括根据给定的规格实现代码的能力，还包括根据需求去进行规划、设计的能力。

Part 5 建议

1. 针对理论课：个人感觉，理论课（尤其是后期）各种各样的术语比较多，比较抽象；同时对这些术语之间的关系缺乏论述。抽象本身没有问题，但是很多时候感觉缺乏具体的论述或例子来支撑。这些术语能不能去掉一部分，或者说，这些术语里面，哪些是最关键的概念，哪些是派生出来的概念。
2. 还是理论课：个人感觉，理论课的课件，条理不够清晰。建议给课件的知识点进行分点，比如第一大点、第二小点等。
3. 针对作业：个人感觉，整个课程代码的复杂度有限。每一次作业的代码量大约是几百行，整个单元最终的代码量大约是1000行左右，一般不超过2000行。感觉如果代码规模适当增大，我们可以更好地理解面向对象的实际思想。

Part 6 线上学习OO的体会

其实线上线下各有利弊，但是总的来说，我觉得OO这种比较抽象的课程，线下授课比线上授课效果可能会更好。但是总体来说，线上授课也是很不错的，毕竟看不懂的地方也可以回看。