一、第四单元作业的架构设计
我认为，不管是 UML 的类图，还是时序图、状态图本质上都是一个图，我们通过构建起一个图来表示元素之间的关系。
由于第一次作业中架构比较差，并没有完全按照元素之间的关系构建出一个图，只构建了部分元素图，对于一些其他元素的查询则直接采用遍历的方式寻找，不过好在作业并没有时间限制，因此这种方法对于实现作业所要求的功能来说并没有问题。
第二次和第三次作业是在第一次作业的基础上直接进行补充的。第二次作业增加了时序图和状态图，实现方式与第一次作业一致，构建了部分图关系，其余的查询操作依靠遍历。第三次作业增加了错误检测，为了保证不影响之前所写的内容，我选择直接新建一个操作类，在这个操作类里面完成所有的错误检测。
本次作业的架构设计方面，存储方式全部使用 HashMap，显然每个元素都对应一个 id，这种情况很适合用 HashMap 来存储。架构方面建立起一个不完全的图，但对于大多数操作来说已经够用，因为多数操作可以直接通过 id 来查找元素，这种情况下 hashmap 寻找已经很方便了，但是对于一些不通过 id 直接查找的情况，就只能遍历所有元素一一对比了。
本次作业中一个类500行的限制是一个问题，但其实出现这个问题的本质原因还是架构设计不好，类相互之间的职能分配出现了问题。以我第二次作业为例，第二次作业写完我的 MyImplementation 类就已经超过500行了，是因为我把所有功能的实现都放在了主类里面，这其实是很不合理的，比如你要查询一个类操作的耦合度，这显然是这个类自己的一个属性，那么这个功能的实现由这个类自己来完成显然更合理一点，在把基本上所有查询功能都下放到各自的类之后 MyImplementation 的行数骤减，并且对于读入和初始化这种重复又冗长的代码我选择构建了一个读入类，这个类只负责数据的读入和初始化，这样把这部分功能又单独提取出来之后使得 MyImplementation 类更加的简明，职责更加单一。总之，就是在这次作业中 MyImplementation 类只当作是一个中间的媒介，负责接收上方要查询的请求，并下发到各各类当中。
这次作业中还有一个坑点就是 UML 元素的某些字段可能为 null，这种情况下拿 null 来查询或操作很容易引发异常，这个我感觉没有一个简单且统一的处理方式，只能在写代码的时候注意调用的元素是否可能为空。
二、在四个单元中的架构设计思维及OO方法理解的演进
第一个单元是表达式解析，刚看到这个题目的时对oo也了解，认为这就是一道普普通通的题，可以通过递归解析，之前也做过类似的但简单的题目，于是就随心所欲地写完了第一次作业，等到这个单元的第二次作业时发现增加了一些元素，于是在原有的代码上修修补补完成了，第三次作业的时候又增加了一些功能，这时我发现我原来没有考虑架构的代码对于复杂问题无法解决，我意识到架构的重要性，于是在第三次作业中重新思考了架构，重构了一遍代码，虽然实现的方法并没有用到树，但整体架构上还是清晰明朗了许多。通过这一单元我意识到了架构设计的重要性。
第二单元是电梯，电梯这个单元让我接触到了许多新的知识，不仅发现了神奇的多线程，而且在架构和oo方法上也了解到了许多经典的模式或操作，例如：单例模式、工厂模式、生产者消费模型等等。并且在写代码之前会先思考一下大体的架构，也会用oo的方法去分析，即什么类管什么属性，什么操作应该归属到哪个类之中，类与类之间如何相互协作带着这些问题去思考我们的作业如何架构。
第三单元是 JML，这单元我其实我对架构设计和oo方法并没有更深的领悟，这一单元基本上就是把 JML 语言翻译成 java 代码，只是在翻译的时候要进行方法上的优化。
第四单元就是本单元，可以说是最能体现oo思想的一个单元，UML 本来就是一种纯面向对象的语言，它内部模型的建立也是根据面向对象的思想来实现的，因此对 UML 图进行解析的时候就需要我们用面向对象的眼光去看待问题。这一单元第一次作业我就没有思考架构问题，于是第二次作业就变得有些困难，在第二次作业重新思考了一遍架构之后就变得很好写了。
总的来说，我认为我们之所以要有架构，要创造出面向对象的编程思想，根本原因还是在于我们的人脑能力是有限的，对于一个稍微复杂一点的问题我们无法直接想出一个解决方法，这时候就需要我们把问题拆分，拆分成一个一个小的问题并且清除各各问题之间的关系，之后再逐一解决拆分后的小问题。面向对象的编程思想就为我们提供了一个解决编程问题的一个通用的方法，我们思考如何保存数据，把什么操作与什么数据绑定，类与类之间如何协作等问题，其实就是在拆分问题。同时我们思考如何架构，这就是在理清我们的思路，帮助我们把问题拆分成不同层次，构建起层与层之间的逻辑关系。
三、在四个单元中的测试
测试这一部分可以说是我oo课最糟糕的一部分，前两个单元完全是自己手动造出一些数据，这种数据虽然特殊性高，但是毕竟是手造，不够多也不够全面，因此前两个单元在这方面吃了许多亏。第三单元尝试写出了一个自动数据生成器和一个自动评测器，但是由于数据的构造不具有特殊性，因此虽然数据巨大，但效果并不是很好。第四单元由于数据生成比较困难，也就没有再生成数据了。
四、课程收获
oo课真的是收获颇丰，这门课程的整体建设做的非常好，无论是课程形式的多样性，还是老师和助教团队的用心程度在北航的课程中都是数一数二的，因此学习体验很好。
在oo课上学到的最根本的肯定还是面对问题如何进行架构以及面向对象的编程思想，这相较于之前学习的 c 语言那种面向过程式编程语言提供了一个看待问题的新视角。
不仅如此，当然很重要的一点是学习到了 java，在oo课中，我们可以随意探索 java的各种用法，各种炫酷的、高级的功能都可以为我们所调用，这能极大的简化我们写代码的难度，这种高级语言相较于 c 来说真的是好写太多了。同时在这门课上也学到了一些经典的模式和方法，这对我们解决问题来说提供了很多基本模型。
还有一点，虽然我的测试做的很差，但是通过oo我还是意识到了测试的重要性，并且也尝试拿 python 来编写测试程序，希望在之后的课程能提升一下自己测试程序的能力。
总的来说，我愿称o课为我目前为止上过最好的课程，没有之一。
五、改进建议
oo课真的已经很好了，但是应作业要求还是提出几点改进建议吧。
-
我觉得如果能再稍微帮助大家学习一下测试程序就更好了，这一部分可以放在先导课程里面，这对于我这种能力较差的同学来说无疑是一个很大的帮助，或许能使得oo课的体验感更好。
-
可以稍微增加一下中测的强度，有时候一个满目疮痍的程序却能过中测......
-
实在没有第三点了。
