Object-oriented end of the fourth unit of the personal summary and summary
Object-oriented courses a semester is over, ingrained from process-oriented thinking into the habit of object-oriented thinking, I look back:
(1) Summary The two unit operations architecture
The first frame work implement :( truncated portion jar Packet Interface)
Analytical thinking:
The structure is based on the realization of the interface, first clear UML diagram of the three layers, interfaces and classes, have the same level where there are class includes local interface, such as a class that implements the interface; followed by the method, a method must be the method of the class or interface, is their lower level; and the same, under the Attribute element is a variable type, that is, its parent class, and similar methods; parameter and the parameter is the lowest level, it belongs to a certain method. Such level of each element will be very clear.
Next, according to each Elements to construct their own values of UMLInteraction , it contains the highest level of Class and Interface, while other elements are subordinate to these two categories, you UMLInteraction is not directly see them, in addition to individual easy to find.
In order to implement the method at all levels, save subordinate elements, save the intermediate variables, I built MyUmLClass and MyUmlInter and MyUmlOper class implementation , the relationship between them, linked by association included.
To build the map Uml the same level, the main advantage is parentId individual elements, but there is a place a pit, parentId a class is not its parent. Only to find inherited elements, in order to determine the parent class. And we use these relationships in the class has a record variable of the parent class (direct change parentId), while the interface, there are records of their parent array.
这就是大体的构建框架方法，与图一致，这样每次查找，层层找下去，一个类的性质可能需要遍历他的方法，参数，变量。
第二次作业框架：（截去实现jar包接口部分）
基本思路和第一次作业一致。只是需要自己建的类更多了，细节更庞杂。但是毫无疑问，仍然层层递进建类，MyStateMachine，MyRegion， MyState和MyInteract， MyTransion这些中间类都能帮助厘清层次。
一旦建好层层的框架，查找各个方法就都很容易了。
但是这次的预检查部分需要动动脑筋，尤其是重复继承的部分。如果没有利用算法，向我这样硬遍历需要厘清和第一次作业的不同。
我主要是利用递归求得类实现的所有接口，和接口实现的所有接口，第一次我采取的是重复则不计入，第二次重复了我算他重复继承，但是没有加入实现的接口，导致递归的下一层接口计算的是消去重复的接口，就会以为该接口没有重复继承。
所以像这种一次次改进的单元作业，一定要理解清楚改了什么需求呀，以及这种改需求会有什么影响。
（2） 总结自己在四个单元中架构设计及OO方法理解的演进
第一个单元，完全是熟悉Java语法，第一次作业按照c语言的思路写了状态机，代码不合风格。之后逐渐将方法写到不同的类里，这时类的思路还没有，不知道要构造不同类的对象。主要是将方法分类分装到各个类里。
第二个单元，架构设计上有所提高。针对不同的对象建立了线程，并且通过一个公共类进行控制和调控。不过此时还不能说是完全面向对象的思想。我的理解更贴近于几个面向过程的线程，在合理的时间开始和消亡。
第三单元，真正开始理解OO方法。课程组提供了成熟的接口，要我们继承并实现接口，这就是一个针对接口的面向对象结构。此时我能够理解一个对象，比如一个类，它有实现的接口方法，有自己的变量。这就是一个有功能，有值的对象，你可以放别的对象进去，你也可以把它放到更大的容器中。
第四单元，根据自己的理解，还原UML图中的容器，把这个对象搭建起来。理解了容器与元素，继承与实现。不得不说，UML图单元真的是能够让人理解面向对象思想。因为UML图本身就是体现面向对象特征的，一下子层次就豁然开朗。
总结下来：面向过程——线程中面向对象和面向过程并行——JML，UML中彻底面向对象。
特别明显的就是main函数的写法，main函数越短，说明这个对象越不需要面向过程，整个交互过程也能给抽象到对象了。
以前面向过程，是单个函数中的思路，现在把面向过程的函数组装起来，就是一个面向对象的容器，有接口，它能实现你想要它实现的功能。我觉得学了一学期后，几乎思路无法面向过程了，而是自然而然开始面向对象了。
（3） 总结自己在四个单元中测试理解与实践的演进
我的测试方法是比较小白的那种，偏向于人肉Debug，的确这使得我的错误率偏高，以后要学会熟练应用Junit进行形式测试，同时学会写对拍器自动生成代码测试。我之前自己用c语言写过一些简单的代码生成方法，但是可能比较傻，感觉不能真的测出问题。实际上针对性debug还是人肉操作比较有效。
所以小白总结自己人肉测试的理解与经验。
1，找到问题：
这个最绝望的是第一单元第三次作业。怎么也找不到错的形式，但就是有一个点过不去。现在回过头想想，第一单元的形式真的是相对固定的，基本上，表达式弄对，先保证某项是对的，然后层层向外递进。错的点是没有加足够的括号，针对*-（-34+78*x）形式。
对于这种不知道错的具体点的debug有两种思路:
一种是细节问题，是不是有笔误，是不是有忽略某点，会不会并级的几个代码有一种是不对的。因为细节错误是没有什么逻辑的，所以适合用大量代码去对拍，找异常数据。当然再没有合适测试代码得时候，人眼观察也非常重要，这就需要代码层次清晰，美观，思路注释到位了。变量函数命名得到就可较少避免犯错。
一种测试逻辑漏洞，我犯得其实属于这种，虽然看着像细节。这种问题起源是没有完全思考懂，直接上手写容易出现这种问题。
这时候就要抽离开已有得（混乱得）代码，当然没有时间重构的化，就画一个代码走向图。我当时的思路是分得挺细的，三角函数和指数函数分了不同的路径，大多数递归返回答案都是有加括号。但由于我对于xy’+x’y这个形式就分了很多种情况讨论，在大框架不清晰时，这种代码写法极容易丢一两个括号，还不易de出来。后来思考，是因为总想着当时就优化，优化不应该为基础思路挡道，如为保证正确在各级求导结果上加括号。
设计时就要把括号的作用研究明白，最好是把几种作用分写成方法函数，用的时候直接调用封装好的方法函数。
嗯，谈测试最后还是到了框架部分，因为框架还是解决bug的最重要的部分。
2，解决问题：
找到问题再解决就较为容易了，我还是很喜欢打印语句+画图。
比如最后的UML图，针对问题打印出所有的继承实现关系，再看哪个环节出了问题，debug并不难。
因为第2，3单元虽然有大量bug，但是不是比较难de的那种，是很傻很明显，的的确确是自己测试没有做好的那种。
我认识到我薄弱的环节真的是在测试，这也与自己的拖延症严重相关，测试每次都没有做得很充分，所以也没有太多的演变的经验，因为实践比较少。相关实践主要在hack和bug修复。
（4）总结自己的课程收获
自己的课程收获分两个方面讲：
1，知识层面：
1， Java 面向对象结构，构建比原来数据结构更为复杂有层次的工程。学习类封装（第一单元），多线程（第二单元），JML语法（第三单元），UML图的架构和各种图的含义与实现（第四单元）。
2， 什么是好的代码，如何通过练习和演进不断优化一次次作业中的代码。减少重复代码，把接口实现尽量用一个函数解决，封装起来。运用各种各样的类、接口，可通过继承、包含的关系使得整个代码涉及的元素有层次的组织起来。这里我认为一个函数60行的要求和一个文件500行的要求起了很大作用，push我去优化结构，并且一旦开始优化，就会想尽量做好。
3， 复习数据结构，并且快速的运用起来。显然，在面向对象课程中，选择合理的数据结构，是可以大量简化代码，优化实现的。尤其在第3，4单元，大量的递归算法，图算法，都要求我们运用HashMap，HashSet等等把元素放置在一个个数据结构中，这样才能合理地调用、计算。其次在数据结构的算法中，我们复习了以前的BST树算法，迪杰斯特拉算法等等，而且在运用上，是快速的通过查找模板，自己改写，测试的方式实现的。也学了新的如并查集这样的算法结构。以前头疼理解好久的图算法，经过离散数学的铺垫和对代码语言的逐渐熟练，可以15分钟半小时写出，感觉好棒。
4， 测试的重要性和如何阅读他人代码。互相hack感觉很残忍，但的确push大家去尝试测试，测试自己的代码，测试他人的代码。本人倾向去使用传统方式，自己用c语言生成测试代码，然后测试大家的代码。看着大家不同的封装形式也是个互相交流和学习的过程。
总之我认为知识层面的收获是综合的。知识点，知识面，对工程的认识，对代码的认识，对数据结构的认识和应用都是知识层面的掌握。
2，能力层面：
1， 这个能力层面和知识不直接关联。就是OO的课程设置，这种测试不公布然后让大家互相想办法通过中测，同时保强测，的确让我们锻炼了互相交流的能力以及…夜肝能力。
2， 好吧，OO还在强制提示我的拖延症不能到过分的程度，我还在斗争，谢谢OO。我会成为更好的自己！
（5）立足于自己的体会给课程提三个具体改进建议
1，理论课因为有些抽象，希望能有个知识框架图之类的东西指导大家学习、理解。
如果有个框架，学习理论课这些继承，实现，类，封装的概念能更清楚吧。
也方便大家对照着找参考书，博客什么之类的。之后可以总结下，内化为自己的知识。
2，比较异想天开的想法，因为讨论区只保留精华，所以不太感问（没有提过问），这个是挺好的。比较小白的问题就都转战水群了，水群的助教也非常认真负责。但是群还是有点水。。所以给课程单开个水群呢？比较民间的建议，然后规定一下格式，比如#提问+关键字，#回答+关键字，#讨论等，方便大家查找聊天内容，当然也可以正常水。水群比较能及时反馈，还可以总结，算是帮带小白吧。
3，我真的想不太出来第三点。感觉课程设置挺好的，讨论区讨论课一应俱全。实验课感觉如果课下给答案就更好了。课上有时不清楚自己做得对不对，课下还是希望知道哪些概念没有清楚。