OOP第四章博客

OOP第四章博客作业

（1）本单元作业架构设计

1）针对于第一次作业，我是将所给类进行了自己的封装，在MyUmlInteraction类里面进行关系的建立，这里把所给的UmlClass建立好，同时有id2Umlclass（id到UmlClass）和name2UmlClass（name到UmlClass）；UmlInterface同样的建立方式；

2）把和相关UmlCLass类的属性，操作，操作的参数，和关联，接口再填入到包装的UmlClass类中；即将一个类所有的东西都包装为一个ClassUml（UmlInterface类似），将所有的“东西装进去”，并且建立相应的查找方法，为接口服务；

3）针对UmlOperation类同样进行一个包装，将参数填入其中；

4）针对UmlAssociation类也建立包装，将End填入其中；（事实证明这一步对于测试要求无意义！）

5）在具体的实现过程中，首先扫描一遍，建立所有的UmlClass的联系，保存其他UmlElement；在第二次循环时，依次建立继承（UmlGeneralization）、属性（UmlAttribute）、操作（UmlOperation）、参数（UmlParameter）、关联端（UmlAssociationEnd）和接口实现（UmlInterfaceRealization）；

6)将具体的查询细节放置在对应的类中进行实现，向外部提供接口；
1）第二次作业的设计，沿袭第一次设计的风格，进一步抽象；

2）把MyGeneralUmlInteration类和具体的包装类的耦合性降低，直接提供一个StarUml类（终极抽象）

3）在StarUml类中进一步细化查询，分为针对Class的StarUmlClass类、针对状态图的StarUmlState类和针对时序图的StarUmlSeqence类；

4）StarUmlclass类添加了check功能，并且向上一层次提供接口；

5）StarUmlState实现关于状态图的关系建立和查询功能的实现以及外部函数接口

6）StarUmlSequence实现了关于时序图的关系建立和查询功能实现以及外部函数接口；

7）最后把顶层的函数依次调用相关函数实现解耦（但是层次化可能有点多，导致同名函数一连串，这也是为了防止混淆！）

（2）四个单元中的架构设计及OO方法的理解演进

第一个单元：这个单元毫无架构设计性可言，完全是强转面向过程，导致代码架构极其复杂以致我再次回看时一时竟无法理解（）；整体是在不断地重构中推到->新建->推到->新建->推到？？，最后选择凑合！于是，层次化不清晰，代码大量冗余，耦合性极高！
第二个单元是多线程，此时对于架构终于明白了一点，但是呢，对于多线程又不懂了，所以还是经过了一次重构，第一次简单的电梯，完全按照简单着来，选择熟悉；第二次选择了分离结构，控制器（dispacher）提取电梯请求（input）再发送给电梯（elevator），整体上按照三个线程类来进行；包括第三次作业也是基于此来设计，同时引入了选择客户分配；
第三个单元是JML；这个单元的设计，其实现在来看会发现有些东西！比如，现在来看这个JML的第一次作业，简单的做完后是第二次好像重来？？毕竟是有时间限制，其实这一单元由于时间的限制会导致在架构设计上需要进行深思熟虑，不然不仅堆在一起不利于bug查找，也会导致低效率！我在这里的翻车点是第三次作业沿袭第二次设计，导致层次化过于混乱，于是引入了一个多余的层次，导致函数的调用总是会多一次白费力气，但是这个函数却是一个被经常使用的函数，于是时间翻倍，直接GG！整体来看，这一单元的架构设计并不好，耦合性较高，不知道该如何解耦，也没有很好的设计，有些粗糙！
第四单元之前叙述过不详细介绍！

四个单元对于OO方法的理解呢，最初是完全不理解的，现在呢，感觉初窥门径？感觉面向对象就是一种抽象层次，设计逻辑关系的思想，而面向过程就是，别问，问就是下一步干啥！面向对象就是谁来干啥；

经过四个单元，感觉第一个单元是入门，第二个单元是理解，第三个单元是应用，第四个单元是综合起来的感觉！因为这个时候写作业感觉已经有一些顺滑，一些明悟了！（真是不容易呢）

（3）测试理解和实践的演进

在第一单元和第二单元的测试中，可能主要偏向于使用数据来尽可能遍历的方法来实现程序的正确性，然后对于逻辑性的检查不是很多；更没有使用过单元测试这种方式；

在第三单元和第四单元中由于作业的类型和前两个单元的不同，这时我发现，这种单个测试方法的作业，单元测试，或者说对于每个方法进行逻辑性检查是一种最有效且bug最不容易发生的方法！而且，对于debug也是相对简单，因为错误容易抓获，这时数据的效果反而不是那么有效；当然，逻辑性的检测，也需要头脑清晰，建议在完成后和小伙伴进行思维碰撞，提前互测（真实致命）！

综合四个单元，对于不同的作业，不同的测试方法的效果确实是大不一样，不能一味依据数据生成器，必须针对作业来进行选择!

（4）课程收获

首先，作为一个成功度过OO的北航学子，收获是终于放假啦颇多的！em，没错，颇多的！

这算是第一次接触面向对象，遥想第一次写作业差点当场暴毙，满脑子想的为什么会有这种设计方法？有什么优势呢？

现在看来，面向对象好啊（真香）；为什么呢？以往的面向过程，注重的是过程设计，在写作业时，会无脑一路往下走，但是感觉很凌乱，对于debug时极为的不利（相对于面向对象来说，当然，设计不好，debug其实没差别，囧）；但是面向对象的设计思想——也是老师一直提到的，也是我一直尝试学习领悟的，如何把一个问题，抽象为几个对象和对象之间的逻辑，通过合理的架构，实现高复用，高解耦，可迭代的代码，而且，在学习的过程中也明白了为什么说更改客户需求会杀死一个程序员，作业的小小需求改变都可能需要我们去重构自己的代码，面向对象的方式确实使得效率有所提升！

另一个收获是jml，uml等和java相关的设计方法和辅助工具等，同时在研讨课上也了解了一些企业关注的点，对于自己的职业规划有一定的帮助吧！

总之，整个课程，最大的收获就是逐步了解并学习了面向对象这一思想，并且了解了现在主流的设计方式就是这种思想，在写作业的过程中也确实学习了很多Java的知识，倒是对于架构的设计还是一知半解，需要继续学习吧！

（5）建议

以下完全为个人看法，不一定具有可实施性，希望客观看待！

不知道其他同学对于互测的态度，但是我个人的感觉是两天不到的时间去研读其他同学的代码，说实话感觉很费力，如果单纯的从找bug出发，我可能根本不会去读代码，只是会选择数据测试；这里费力仅仅体现于有7份代码，但是同时还有恐怖的OS呢，所以时间或者互测的人数是否有协调的可能性和可实施性呢？
对于每一个单元，是否会有一个标程呢（正对萌新和不知所措的选手），然后比对自己的进行进一步的学习（有注释就最好了）；不过这一学期助教确实很辛苦，需要对OO改革付出巨大精力，先感谢一波付出！那么下一届助教呢
目前好像是没建议了，在截止前想到再补吧！