- （1）第四单元两次作业的架构设计
- （2）四个单元中架构设计及OO方法理解的演进
- （3）四个单元中测试理解与实践的演进
- （4）课程收获与总结
- （5）体会与建议
一、第四单元两次作业的架构设计
1.第四单元第一次作业架构设计
需求分析:第四单元第一次作业我们需要简单地解析UML类图。由于在UML图中，所有的内容都可以被看做对象，所以UML图从输入的角度来看，输入的是一个一个被打乱的对象，如果不对数据进行组织，设计一个优雅的数据结构，那么在实现的过程中就容易出现代码杂乱、容易出错的现象。所以第一次作业的重点是——设计优雅的数据结构，方便的支持UML图的操作。
从UML本身的特性出发，设计了UML_Struct，由于接口和类在UML图中的地位基本等价，所以可以将接口和类统一使用UML_Struct来管理.UML_Struct本身包含的信息应该包括:1.Class(Interface)本身具有的信息 2.其属性3.其方法 4.其关联关系 5.其实现关系. 6.其继承关系
其中UMLClass和UMLInterface的方法还进一步的具有参数特性，所以针对参数，单独设置了一个类。因此所有的操作全部都封装在自己设计的数据结构中。在第一次作业中仍然大量使用了缓存的技术，将所有信息整理到一个数据结构中，这样对于某一个类的所有操作都非常灵活。
架构如上图所示，在MyUmlInteraction中负责抽象和整理出UmlStruct类和OpStruct类。同时MyUmlInteraction的所有操作都由UmlStruct支持，并且复杂度屏蔽在UmlStruct中。
2.第四单元第一次作业架构设计
需求分析:第四单元第二次作业我们需要增加UML类图规则检查以及顺序图和状态图的解析。首先针对UML类图检查，由于第一次作业已经将所有的关于类图本身的信息封装在了UMLSTRUCT中，所以本次作业可以将规则检查部分归并第一次作业中，顺序图和状态图的解析单独在最上层的类中实现。
设计架构如下所示：
可以从类图中看出，第二次作业采用和第一作业一样的思想，尽可能地设计优雅地数据结构，将不相关的问题封装到不同的类中，方便管理。顺序图和状态图的操作相对简单，所以单独设计一个类非常好管理。第二次作业中，UML类图的第二条和第三条检查规则，都对应了离散数学中的图问题，所以可以把实现和继承关系看作邮箱边，把类和接口看作点，进行抽象建图，把问题从复杂的UML架构中剥离出来，单独实现图论的相关算法。这样的架构设计，虽然相对复杂，但是延展性和纠错性极好。
二、四个单元中架构设计和OO方法的演进
1.第一单元作业
在开始第一单元的架构设计时，初步的从数据抽象的角度来理解了对象，开始能过够考虑把相关的数据抽象成一个类。同时也开始了解了继承的相关知识，能够抽象出一个比较基础的父类，然后再将其扩展成几个不同的子类。但是第一单元整体设计的不足还是非常明显的，设计第一单元三次作业架构时几乎没考虑下一次作业将会怎样处理，所以导致了次次作业次次重构，一直重构一直爽。尤其是作业结束后使用分析代码的工具来分析自己代码时，能够看出诸如没有及时分拆成多个类，类中代码冗余、代码中出现magic number等不合适的地方。当然这样为之后的作业风格打下了基础。
2.第二单元作业
第二单元是多线程的设计。在这一单元中，将线程本身也看作是一个对象是最核心的内容。只有理解了线程是一个对象，才能够游刃有余的驾驭多线程的控制。在第二单元伊始，对多线程对象理解的不足导致写下了非常多的bug，但是随着理解的深入，多线程的基本操作都可以顺利的完成。第二单元作业吸取了第一次作业中的诸多教训，如不会写magic number，所有的常数均使用final 变量予以命名(实际上也发现，这在第二三次作业的改动上有了极大的便利，否则magic nubmer大规模修改也极易导致bug)。同时第二单元作业，在最开始设计的时候就考虑到了单电梯向多电梯的扩展，向捎带算法的扩展，所以在第二次第三次作业的时候写的十分顺手，体会到了面向对象封装性和延展性的优点。
3.第三单元作业
第三单元作业开始，就不是所有内容都是自己设计的了。需要配合开源库，填充完善部分代码。所以第三单元的设计中心放在了数据结构上，因为整个开源库的架构都已经设计好了，我们只需要实现其中的一部分。JML的特点就是对一个方法的理解基于JML即可，不需要过多的依赖其他方法的理解，使得在检验正确性的时候可以专注于一个方法的检查。第三单元作业可以说除了多线程部分，其他部分写的都非常优雅， 一开始便将图抽象程一个单独的类，将所有的图算法在一张简洁的图上进行，执行完图算法后，将图算法的结果再还原为原本的类中信息。这样就剥离开了算法和繁杂的其他信息，使得能够专注于算法的编写和其他比较简单的过程的编写，使得代码风格比较优雅，不容易出现错误。尤其是第三次作业中，设计了一个类图，能够支持多种地铁系统计算需求，在使用时只需要，实例化三个不同的对象，同时传入不同的边权值即可完成相关任务，代码简洁而优雅。
4.第四单元作业
第四单元作业同样是在开源库的支持下实现一小部分的功能，同第三次作业一样，重点在于如何设计高效、优雅、延展性好的数据结构。前文第四单元设计已经提到，UML的输入是一条一条的杂乱对象，必须首先统一起来。所以第四次作业可以说是自然的，也可以说是由于前三次作业的训练，使得第四单元作业的编写过程中，能够合理的采用数据抽象，从不同的层次管理数据，不同的类之间封装协作，比较高效而又优雅的完成。
三、四个单元中测试理解与实践的演进
虽然我们的面向对象课程没有引入互测环节，但是我们在对自己代码的测评上依然有了很多的尝试和理解。在第一单元多项式作业中，就体会到两类测试方法。首先写完自己代码之后，一定要重新阅读需求，同时浏览自己代码对照是否按照需求的要求进行实现。这样第一遍过后一般不会出现设计理解上的巨大偏差。第二遍就是要检查实现上的错误，首先进行小规模的数据进行测试，测试通过后在对各个问题情景分情况进行讨论。力求测试点能够覆盖所有的情况。第三遍测试是大规模的暴力测试。这不仅需要自己写一个数据生成器生成合理的输入数据，同时也需要写一个检验正确性的测评机(体验一把助教的快乐)，通过大规模的测试包括边界压力测试之后程序通过强测应该就没问题了。到了多线程的第二单元，问题在于线程问题通常难以复现，第一遍和第二遍的小规模测试意义并不是特别大。第三遍的测试，尤其是长时间的重复随机测试就非常有意义，因为只有尝试了足够多的次数，才可以说随机生成的一般情况下代码没有问题。第三次和第四次作业中，问题在于，由于开源库的限制，我们几乎不可能生成一个答案检验器，所以这个时候我们就想到了多人对拍的策略，设一个人出错的概率是x，那么n个人同时出错的概率是....0!所以，我们在后面两个单元的测试中采用了多人对拍的框架，每人提供自己的jar包和一定的测试数据，随机产生询问需求，进行测试，群策群智来解决正确性的问题。
四、课程收获与总结
首先在本门课程中，最最最小的收获就是熟悉了java语言，可以熟练的使用java语言完成一些简单的程序。其次，在操作系统理论课程中学习的多线程理论在java上有了实现，亲身体验了死锁的快乐。比如哲学家就餐问题，这种线程场景在自己代码中也确实能够实践和感受出来。在面向对象的课程中其实不仅仅是面向对象知识的学习，我们使用了非常多的工具，比如风格检查工具、代码分析工具，UML画图工具，线程监控工具等等等等，这些工具都帮助我们写出更好的代码，并且检验自己代码中的不足，理清面向对象的思想，欲善其事，必利其器。所以这些工具的使用也启发着我们在以后的工作学习中去善于发现和应用各种各样的工具，通过已有的工具来改进和完善自己。在本门课程中，虽然没有具体统计，但是实实在在的这么多次代码作业和博客作业中训练了自己的工程能力，作为计算机专业的学生，拳不离手是非常非常重要的。最最最重要的收获是当然是面向对象的思想，无论是从面向对象语言的角度还是从JML规格的角度还是从UML语言建模的角度，我们确确实实从多个角度来理解面向对象，应用面向对象，尤其是工厂模式、订阅发布者模式等等设计模式也都有了接触，让我们有意识地去识别设计模式，思考设计模式。从一个规范的程序员地角度来编写程序、科班出身有科班出身的样子。
五、体会与建议
面向对象作业分为博客总结作业和代码作业。代码作业在第一单元不熟悉Java语言的情况下可能需要花两天左右的时间来完成。到了后面几次作业无论是编程作业还是博客作业都基本可以控制在一天的时间左右完成。在这里要特别感谢和我一起讨论一起share测评的同学，因为大家一起思考一起讨论所以在很多方面都节省了一定的精力。同时虽然没有在讨论区发言，但是一直关注着讨论区，讨论区提出的问题和老师助教们的解答确实有着不少的帮助。跟之前学习面向对象的同学交流的时候了解到，今年的面向对象课程有了很多的改革，尤其是输入输出接口方面给了同学们很大的便利，所以OO整个过程的体验感其实是不错的。
建议:
1.将博客作业是不是可以考虑变换为实验报告的形式，或制作ppt分享什么的，因为在看同学们的写的博客的时候感觉收获并不大，比较深刻的反思鲜有其数。
2.课上上机是否可以加更多的说明，因为感觉课上作业虽然并不难，但是如果变换为针对上课讲的知识进一步的加以引导和解释可能会更好一些。
3.理论课的讲授也布置一些和纯理论不是编程实现的作业，因为感觉理论课上讲述的一些东西没有完全通过编程来实现，可以加一些理论作业加以引导。