OOP第四章博客

OOP第四章博客做业

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

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)将具体的查询细节放置在对应的类中进行实现，向外部提供接口；
   

2. 1）第二次做业的设计，沿袭第一次设计的风格，进一步抽象；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（4）课程收获

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

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

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

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

总之，整个课程，最大的收获就是逐步了解并学习了面向对象这一思想，而且了解了如今主流的设计方式就是这种思想，在写做业的过程当中也确实学习了不少Java的知识，却是对于架构的设计仍是只知其一;不知其二，须要继续学习吧！

（5）建议

如下彻底为我的见解，不必定具备可实施性，但愿客观看待！

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