两次作业的架构分析

第一次

针对于第一次的作业，考虑到包含有各种各样的UML的类，并且这些类中已经提供了众多的方法，起初为了方便使用这些官方包的代码提供的功能，考虑自己实现一些My类，与UML类相对应的进行继承，但在过程中发现，官方包的这些类的内容都没有提供有效的构造，无法实现。退而求其次，将UML类作为My类的内部成员的变量，从而实现信息的共享。

例如，我所实现的一些My类。

具体以MyClass类来讲，在类图解析阶段，我对于类的继承，关联，类内方法，实现接口等信息，都作为MyClass类内部的一些私有的变量进行存储，同时提供了一些public方法来获取类的信息（例如关联哪些类和接口等）

 例如，其中关于类的实现接口的部分如下图。

 1 private ArrayList<MyInterface> interfaces;
 2 
 3 public void add(MyInterface myInterface) {
 4     interfaces.add(myInterface);
 5 }
 6 
 7 //实现的所有接口，包括接口父类 无去重
 8 public ArrayList<MyInterface> getInterfaces() {
 9     ArrayList<MyInterface> arrayList = new ArrayList<>();
10     for (MyInterface myInterface : interfaces) {
11         arrayList.add(myInterface);
12　　　　　 //getAllFathers为MyInterface类获取父类的方法
13         arrayList.addAll(myInterface.getAllFathers());
14     }
15     return arrayList;
16 }

使用ArrayList存储MyInterface类对象，在类图读入进行解析时进行添加。

获取类实现的全部接口提供了相应的方法。

第二次

针对第二次作业，进行了类的扩展，基于上次作业，添加了相应的新类。

第二次作业的难点实际上在于根据上次作业的内容完成几个check。

 检查循环继承时，我使用了极其笨拙的方法：针对每个类，不断获取父类，将路径上的类存储。若获取到了其自身，则将其添加到循环继承类的数组中；若获取到了其他的非自身的类，则停止。

这样的一个办法实际上复杂度很高，但对于实在不想改架构的我，这很好。

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

第一单元主要建立了单项式类和多项式类。

第二单元建立了电梯类和调度器类。

第三单元完成了地铁图的一个邻接表类，完成主要功能。

第四单元完成一些UML对应的My类（详见上文）。

感觉自己对于OO的理解似乎并没啥进步呢。。。

主要感觉自己在构架时，从类出发，对于一些内容进行相应的封装。都有对读入内容的解析类，然后就生成相应的功能类。

例如，第一单元，建立功能类（单项式和多项式），而后在主类Main中的main方法进行读入与解析，生成相应的单项式和多项式。

四个单元中测试理解与实践的演进

个人感觉，经过了精心的架构设计和走心的代码书写，可以极大的降低debug的工作量。

在前几次的作业当中，还算是比较认真的完成了各次的作业，代码完成后进行了一些小规模的测试，通过中测。

而在最后的两次作业当中，逐渐的有些懈怠下来，没有了设计，一些逻辑的正确性我自己都不清楚。。。

 阅读代码对bug的找寻更有针对性。

课程收获

作为一门以写代码为核心的课，当然最大的收获就是有了大量的代码书写的收获。从设计到书写再到测试，提高了计算机人员的基础的代码能力，这种好处无疑是极大的 。

其次，团队意识也有所提高，大家互相分享自己的设计，互相帮助debug，一起完成一个评测机的项目。

总的而言，OO课程丰富，提供了许多优秀的软件等待学习。

课程建议

1.个人认为这个互测时间匆忙，适当延长时间。个人认为读别人的代码是挺好的体验（尽管可能会觉得乱七八糟而吐槽），而OO项目少则三四百行，多则上千行，每组七个人，想要全部读一遍，并寻找错误还是耗时的。

2.对于课上测试，考虑提供课下继续学习的窗口，并发布参考答案（个人感觉课上测试意义不大）。

3.助教团队完成官方包不易，书写参考书不易，但最后的作业其实指导书没有对一些问题解释清楚。