面向对象课程总体总结
面向对象第四单元作业架构总结
第四次作业主要围绕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实质上的目的是为了让类的功能更加的内聚减少外部耦合。同时在这个基础之上，类和类之间存在逻辑的相似性，如果是子集关系，可以采用继承的方式实现，如果是并集关系，可以采用多个类实现某个接口的方式来组合类和类之间的关系。尤其是对于最后一次作业的实现，让我很深刻理解了架构的重要作用。通过自顶向下的将数据进行分解处理，再利用接口对具有相同操作的类进行整合，使得这个编码问题变得更加有条理，在处理的时候也觉得更加方便。
第二单元
第二次作业是多线程的作业内容，这部分主要的难点在于两个一个是对于多线程之间协作的规则的确定，保证同步性。这次作业的主要的多线程模型是生产者-消费者模型。在这次作业的完成过程中，以及上课的内容我了解到了很多关于面向对象的程序的很多常见的架构， 通过对这些常见架构的学习，将之前处在萌芽状态中的结构化思想可以有意识地应用于代码实现的过程中。同时，对于代码的实现过程，我认为无论是多简单的程序，在编码之前都应该经过比较详细的设计，同时在编码的过程中，也不应该为了一时的方便而去修改最开始定下的函数接口，否则在多个类进行协作的过程中，会在边界值的位置出现很多难以修改的bug。
这部分对于我的面向对象的能力提高在于提高了对于类和类之间消息交互的结构设计能力。提高了类的内聚程度，使得类和类之间只有必要的消息能够相互交流，尽量减少对外的方法。
同时学习关于面向对象的设计原则SOLID：
1.单一功能原则：对象具有的功能应该单一
2.开放封闭原则：程序对于拓展开放但是对于修改封闭
3、里氏替换原则：程序的对象应该可以再不改变程序正确性的前提下可以用子类进行代替。
4，接口隔离原则：多个特定客户端接口好于一个宽泛用途的接口
5.依赖翻转原则：一个方法应该遵从抽象而不是一个实例，代码应该取决于抽象盖念而不是一个实例
第三单元
第三单元是围绕JML，JAVA建模语言的编程。依靠对于程序的规格阅读完成程序。在作业层面架构的设计不是很难，但是对于规范化的设计角度来说，可以学到很多东西。通过UML建模语言可以很清楚的确定方法，类的接口规则，同时在实现过程中也会更专注于某块代码的书写，而不用考虑某个方法在整体中应该起到一个什么样的作用。代码的完成效率变高了很多。
第四单元
主要是学习了UML，对于这个单元的作业对于架构的促进不大，比较简单，只涉及到了简单的查询，没有涉及到很复杂的不同图之间的交互问题，但是对于UML图的学习可以让我们在设计和展示代码结构有了一种全新的方法，也能看懂一些利用UML展示的程序结构。
实践和测试在OO课程中的演进
主要谈一谈测试，因为实践的进步主要体现在代码设计放面，而代码的设计主要取决于架构的理解，而架构在上面已经谈过了。
关于测试方法
对于测试，我觉得任务量并不比编写代码轻松。学习OO课程之前，有编译和机组两门对正确性要求很高的课程，但是我对于测试的理解仅仅在于生成比较大量的测试样例，然后传入程序观察结果是否正确。这样的做法是有效的，但是却并不能很好的杜绝问题的出现。
通过面向对象的课程的学习，我认为测试应该先进行单元测试，之后进行整体测试。应该从部分开始对程序的正确性进行检查之后再对整体进行大量的测试。同时测试点应该涵盖需求中的边界情况。
关于测试工具
主要的测试工具有两种，一种是Junit，测试某个类某个单元是否符合设计需求，对方法的边界进行测试，同时尽量涵盖方法的所有分支。但是对于很多需要类和类之间协作的功能的测试可以采用脚本测试的方法，分成两部分测试数据，一部分是通过阅读需求确定比较特殊的测试点，另一种则是通过随机脚本大量生成的测试样例。对于多线程代码以及对性能有要求的代码这种随机测试的效果都比较好。
课程的收获
1.最大的收获就是对JAVA语言更加熟练，对于其中的数据结构的灵活使用程度提高了。
2.在OO课程中也是我第一次完成一个多线程协作的代码，通过实践了解了多线程使用中的各种问题，包括死锁和死等问题，同步性的问题，和这些问题的解决方法以及多线程程序的架构。
3.学会了很多对开发很有用的工具，比如Jprofile，Junit，以及UML等。
4.对于程序设计的思维也更加成熟了，同时复习了一些跟图论相关的算法，对程序正确性的保证有了一些提高。
对课程组的建议
1.课程上应该补充一些比较复杂的例子来让我们理解架构的重要意义，架构设计是为了复杂问题产生的，所以通过比较复杂的问题采用架构比较清晰的解决会更加帮助我们学习这部分重要的技能。
2.后半程的指导书可以再做一些优化，UML图部分感觉要求不是很清楚，同时UML部分的作业设计并不能让我们很好的学会UML图，可以对一些需要图和图之间交互的问题进行查找，比如一些简单的类图和状态图的一致性问题等。
3.多线程部分接触到的多线程模型基本上只有生产者--消费者模型，可以补充一些其他的多线程模型放在实验中学习。
