oo总结

架构设计

第一次作业

1. 需求分析
   这次作业是针对类中的一些元素，如属性，操作，继承，实现等查询，所以这次的架构我们的第一感觉，按照正常的结构在类中存属性操作，继承的父类和实现的接口等。

2. 具体功能
   为了实现这次功能，我大致把这次作业分为了这样几个部分。

   • 首先是初始化，如何在构造函数中，把UmlElement的数组初始化为我们设计好的结构，这一部分也是最难的部分。
   • 第二是指令实现的模式，大致的模式就是在核心类中实现相应的方法，然后在对应的元素类中提供查询的支持。
   • 第三是一些具体的算法，对于一些特殊的查询指令我们需要具体考虑他的算法，如得到所有实现的接口，可以直接用BFS跑一遍，得到结果。

3. 对于扩展性的一些改进
   对于上面的架构设计，虽然能够完成功能，但是无疑是有这很大的缺陷的。

   • 首先是可供查询的扩展不足，如果我们直接在class中保存它关联的类，而没有保存associationEnd的话，对于associationEnd中的属性我们就不能够提供查询的支持。
   • 其次是class类过于复杂，我们把所有的东西挤在一个类中，他的方法过于复杂。
   • 第三，是初始化时，我们需要在核心交互类中实现每种UmlElement的初始化方法，然后通过switch来判断，使得交互类中含有大量的初始化方法，同时对于用户不够友好，需要记住很多不同的初始化方法的使用。

   所以，我模仿了官方接口中的策略，为每一个元素建立一个类，然后建立一个公共的抽象父类，在父类中维护一个初始化方法的map，而在每个元素类中分别实现自己的初始化方法。这样对于用户来说，就只需要使用一个方法。

第二次作业

1. 需求分析
   第二次作业，需要支持时序图，状态图，和三个合理性检查。首先对于时序图和状态图，和第一次的作业的方法并无区别，可以直接沿用上次的方法。合理性检查似乎与时序图和状态图无关，可以单独实现。所以这次作业的思路也很明确，先按照上一次的方法，分别实现时序图和状态图的查询，然后在考虑具体的算法来实现三个检查。
2. 具体实现
   在实现时序图和状态图的过程中没有遇到什么困难。只是Pseudostate，finalstate，和普通state这三个在元素，按照数据的限制，完全可以当作同一种元素，而如果分别处理的话则在类型强转的时候会发生困难。所以又为这三种元素建立了一个公共的父类。这也是符合面向对象的思想的。
3. 在实现三个检查的功能时，遇到了一些困难。首先发现三个检查都可以类似的用BFS来解决，但是三个的BFS又不完全相同，而第一次作业所实现的功能并不能完全支持这三个检查，所以就写了三个相似度非常高的BFS，没有找到好的方法代替。

四个单元oo思想和架构的演进

1. 第一单元
   第一单元，由于基础的欠缺和锻炼的缺少，基本还是按照面向过程的思想，即缺少哪个功能就写一个函数，缺少什么数据结构就增加一个属性，对于类的划分也是按照最基本的方法之间的相关性，对于架构来说，由于类划分的不够良好，所以各个类之间的耦合性和依赖性非常强，算是对java的基础做了一个充分的练习。
2. 第二单元
   第二单元，借助作业的特性，开始注意到oo的各个模式的应用，也简单用到了单例模式和工厂模式，但是一直感觉都是为了用而用，没有体会到精髓，但是也是作为一种练习吧。这次作业中一个简单的架构是很清晰的即分为输入，调度，电梯。所以这一单元的架构降低了一些耦合性，各次作业之间也减少了重构程度。
3. 第三单元
   第三单元是jml的练习。这一单元对继承以及在继承之间功能的扩展有了一定的认识，基本能够做到在尽少的修改已有代码的情况下通过继承实现功能的扩展，同时对封装也有了更深的认识。例如我们在实现Graph类时，要在内部实现一些图的算法，为了降低耦合性，提高扩展性，我把各种算法进行了封装，在体会封装的程度以及要为封装的类实现怎样的功能时，通过站在用户的角度去看待这个问题，就会清晰很多，即如果我要用这个类，我希望类的作者给我提供怎样的功能。整体的架构也规整了许多。但是由于算法基础的薄弱在实现一些较为复杂的算法时还会出现结构混乱的情况。
4. 第四单元
   第四单元看似算法等难度不大，但是它涉及到的内容，整体的复杂程度还是很大的，对于整体的结构把握还是有很大的挑战，尤其是在结构和数据之间关系复杂的情况下，实现一些简单的算法也显得有些困难。在这一单元，对于类的继承，各种类型之间的转换关系，复杂数据关系的结构把握都有了一定的锻炼。这一单元的架构，在实现查询指令时还是很清晰，很容易把握，但是当需要一些算法时就会出现填补的情况。这一单元对于oo的思想有了一个很大的改变。之前对于oo还是考虑他的方法是什么，他的类型是什么，从功能的角度去使用和看待这些类，这次突然发现我们只需要考虑它什么，例如各个元素都是UmlElement，而我们一个方法就需要UmElement，只是一个简单的例子，但是可以发现我们逐渐有了oo的思想。

测试的实践演进

对于测试，主要从两个方面有了进步。一个是测试方法，另一个是测试数据。

• 对于测试方法，之前主要是依靠手动输入数据，但是这种方法无疑是低效的，而且不是总会有效，尤其是对于多线程的程序，对于一些线程问题很难通过手动输入数据来测出bug。后来多采用了自动的评测机，进行大量的测试。配合JUnit来进行每个方法正确性的测试。
• 对于测试数据来说，之前基本是靠自己去想。通过JUnit我们对每个方法的每个分支去测试，有助于我们发现一些边界数据。也可以通过一些jml工具等进行辅助测试。

课程的收获

这个学期oo这门课程，从java的零基础到能够写出一个较为复杂的程序，首先非常感谢助教的辛苦付出（可能比我们写的代码还多。虽然课程不算轻松，但付出总会有回报，这门课程也让我们收获良多。除了最基本的java基础。更重要的也是我们一直强调的oo的架构设计和oo思想。但是我觉得更重要的是我们的学习能力，对问题的解决能力和面对困难问题的处理。尤其是对每一单元的最后的作业，例如第一单元，最后的求导第一眼看到让人一点头绪没有，通过一天的思考未果后更是达到了令人绝望的程度。但是慢慢坚持下来，一点一点去分析，一点一点摸索，最后解决这个问题。这个过程我认为是最让我们有收获的，我们想要进步，就一定不会总是遇到简单的问题，遇到越多的挑战我们才能进步的越快，那么怎样去解决这些问题，oo的课程给了我莫大的帮助。

课程的建议

最后是课程的建议，也希望oo能够越来越好。

• 第一，难度的分配，例如jml第一次作业和第三次之间跨度有点大。虽然有些挑战是好，但是跨度过大不利于架构的演进，有时候为了莽出最后一次作业会导致架构变得一团糟。
• 第二，基本知识提供。老师在课上更多讲的是一种思想。但是java的一些硬性的基础知识有时候也非常重要。例如在电梯作业中，java多线程的只是对完成的作业占了很大的重要性，虽然是鼓励我们自学，但是每个人查到的资料水平参差不一，有可能对多线程有了错误的认识，对于作业造成了很大的困扰。
• 第三，需求透露。可以在某一单元中提前透露下一次的需求，可以更具体一点。能够让同学们有一次这样的锻炼，加深体会。

转载于:https://www.cnblogs.com/qsblublu/p/11060710.html