第四单元作业总结
面向对象第单元作业架构总结
第四次作业主要围绕UML图展开，UML（Unified Modeling Language，统一建模语言）是一种建模和归约的语言，可以帮助我们对面向对象程序的类图以及类之间的交互和类的状态变化进行建模。这次的作业的主要内容是利用课程组提供的UML的解析工具，来完成对UML图的一些查询工作。
第一次作业的架构
第一次作业的主要内容是完成对UML类图的相关内容的查询，需要完成的查询功能有：
1.类图中一共有多少个类
2.某个类中有多少个操作
3.类的属性有多少个
4.类有多少个关联
5.类的关联对端是哪些类
6.类的操作可见性
7.类的属性可见性
8.类的顶级父类
9.类实现的全部接口
10.类是否违背信息隐藏规则
对于关联关系需要考虑父类。
通过对于需求的理解，我们可以发现，对于第一次作业涉及的访问过程有：
1.类->该类中的属性
2.类->该类中的操作
3.操作->操作中的参数
4.类、接口->类、接口的关联对端
5.类->该类的父类
这次作业的9种查询就是对这几种访问顺序的综合过程。比如对于关联关系的查询可以先找到该类及该类的父类，构成集合A，再对集合A中的类查询关联对端。基于这种理解，我将访问过程抽象成一个类Mapper，然后实例化五个对象，分别完成这个访问过程的查询工作，然后一个类负责在Mapper的基础之上完成全部的查询工作。
第二次的作业架构
第二次作业要求在第一次作业的基础之上完成以下几项任务：
1.完成对类图中的继承关系和属性命名的检查（UML002，UML008，UML009）
2.完成对顺序图的查询
3.完成对状态图的查询。
算法上比较难的一个部分是对继承关系的检查，要求类、接口不能出现循环继承和重复继承。检查算法为：从每个在继承关系中出现的类S开始，对整个继承关系图采用BFS进行遍历，同时保存在遍历过程中的前序，如果在遍历过程中发现遇到了S，则说明在这个遍历过程中出现了环。对于重复继承也是同样，只是在BFS遍历过程中发现经过了一个类两次则说明出现了重复继承。
对于架构的设计，关于类图的检查，采用继承上次作业中的Mapper，在其中增加对继承关系的检查。对于状态图和顺序图的检查，如果都放在同一个类中变的过于臃肿。所以将查询分成类图查询，状态图查询，顺序图查询三个类完成，由一个类通过调用这三个类的对象来完成整个查询工作。
OO课程中对于面向对象思维的演进
这次面向对象的课程中，对我面向对象思维影响最大的作业是第一次关于复杂多项式求导问题的实现，以及第二次关于多线程电梯的实现。
在学习面向课程之前曾学习过C++，所以对面向对象这个名词并不陌生，但是却并没有在实际的应用中实践过面向对象的相关思想。对于面向对象的理解仅仅停留在形式，在编写代码的过程中不会从面向对象的角度对需求进行功能划分，而是在思考完成这项需求，需要完成几个阶段，然后对这几个阶段进行面向对象形式的封装。
第一单元的作业完成让我对面向对象的思维有了更加深刻的理解。主要原因是因为在这个单元中，三次作业我重构了三次，随着这三次重构，我对面向对象的思想的理解演进了很多。第一次作业是一个完全的面向过程的程序。第二次作业徒有面向对象包装的面向过程程序，而第三次作业则是完全根据面向对象的思想进行面向对象设计的一次代码实现。面向对象的思维是将程序看成是几个部分的协作过程，每个部分是独立的，即一个类，其内部变量要设置成private实质上的目的是为了让类的功能更加的内聚减少外部耦合。同时在这个基础之上，类和类之间存在逻辑的相似性，如果是子集关系，可以采用继承的方式实现，如果是并集关系，可以采用多个类实现某个接口的方式来组合类和类之间的关系。尤其是对于最后一次作业的实现，让我很深刻理解了架构的重要作用。通过自顶向下的将数据进行分解处理，再利用接口对具有相同操作的类进行整合，使得这个编码问题变得更加有条理，在处理的时候也觉得更加方便。
第二次作业是多线程的作业内容，这部分主要的难点在于两个一个是对于多线程之间协作的规则的确定，保证同步性。这次作业的主要的多线程模型是生产者-消费者模型。在这次作业的完成过程中，以及上课的内容我了解到了很多关于面向对象的程序的很多常见的架构，
第二个部分就是对程序的整体结构的设计。这里让我觉得比较关键的几点是：
1.要在开始编写代码的时候规定好方法的输入输出接口，保证一个方法的输入/输出在边界位置是良好规定的，会为之后的代码处理节省很多时间。
2.一定要在编写代码之前对程序进行比较详细的设计 ，不应该在代码编写的时候一时的方便任意改变最开始的设计，这样会导致在类间协作的过程中在边界值位置出现很多问题。