OO第四次博客作业

本单元两次作业的架构设计

第一次作业

建图层面

采用包装器的设计模式。在建图时用包装器类来建立层次关系。由于Class和Interface有很多操作有相同接口，但具体实现又有不同。所以建立ClassOrInterface接口，方便统一管理。而Class和Interface可以有自己的属性如Op，Attribute，以及ClassOrInterface的容器。

建图时具体操作：1. 先扫描一遍传入的所有UmlElement，建立相应的包装器对象。2.再扫描一遍所有UmlElement，确定各个包装器对象的之间的关系。最终建立起一个类似于广义表的结构。

指令层面

由于已经建立起层次关系。绝大多数指令都可以拆解成子任务，交给不同的对象去完成。比如查询class中某Attribute的Visibility时，最高层的类负责找到对应的class包装类，对应的class包装类查询对应的Attribute类，再由对应的Attribute类查询Visibility并返回。

第二次作业

建图层面

延续第一次作业采用包装器的设计模式。在建图时用包装器建立层次关系。如处理状态图时，分别建立了 stateMachine，region，state的包装器。stateMachineWrap有regionWrap的容器，regionWrap有stateWrap的容器。stateWrap有其他stateWrap的容器，来表示状态之间的各种关系。类图，顺序图类似。

指令层面

因为建立的层次关系。所以每个指令都可以拆解成不同的子任务，交给不同的类去做。所以实现某条指令，即是在对应的类层次中实现一个方法（或者接口）。最高层的类，即实现所有接口的类，仅仅是调用对应方法。

按照指令的逻辑来分类，可以建立四个类，分别实现相应的接口，来管理类图，顺序图，状态图，正确性检验。又由于建图应该只进行一次，所以创建了Constructor类，专门用于建图，并且将相应的容器传给上述四个类，便于其管理自己的需要管理的部分。

架构设计及OO方法理解的演进

第一单元理解

最开始对OO这个玩意儿并没有概念，代码能跑已经谢天谢地了。所以写出来的代码各种复杂度都很高。而且很容易犯错误。

第二单元理解

接触到一些设计模式。例如工厂模式，观察者模式，builder模式，包装器模式。看介绍时候会觉得这个模式很有用，但到了写代码时又难以应用到具体的代码中。

看了一些大佬们的代码，发现策略和机制真的可以分离。一个电梯可以用不同的调度策略，只需要new不同的调度器就可以了。觉得很神奇。也发现一些设计模式，具体应该怎么用，怎么做可以适应自己的代码需求。

第三单元理解

 

测试理解与实践的演进

从电梯作业开始写评测机，一直到期末结束。这期间体会到了多人协作编程的乐趣（乐趣？）。常常感觉自己写的评测机要比OO作业更OO。也可能是评测机的逻辑相对比较简单容易。

测试的重要性，已经不用多说了。毕竟，它屡次让我这种D组级别的架构，也有机会苟到A组瞧一瞧大佬的世界。甚至都觉得这门课可以改名成 shell，python混合编程实践

虽然之后我们也学习了JML，Junit等等方法，但是黑盒测试还是不能少。经验来看，高强度高密度的黑盒测试所检查出的bug会更容易。而且黑盒测试，比较省力气。

手写评测机也保证了互测阶段的省事儿。就是有了评测机后，互测看代码就很少了。

课程收获

1. 平均每周附带一次shell，python混合编程实践。

2. 不管写什么，都有想先写个类的冲动。

3. 克制。不急于编程。写的急就必然得重构。而克制可以省事很多。例如我们可以等到ddl再开始写。没写出来就更省事了

4. 设计模式是很用的东西。走过弯路才会想着用系列。

改进建议

1. “看代码比写代码重要”。这是这学期OO课和OS课都有的一个感受。想要得到快速进步，学习A组大佬们的代码组织方式其实要比自己写代码“苟”进A组要更有意义。建议每单元结束时，可以尽早开源比较优秀的作业。或者开源标程。这样在每单元末总结的时候才有机会做更深入的反思。说实话，如果不是看过架构超级棒的代码，我会认为OO课上教的内些东西全都是空话。

2. OO和OS这种较硬核的课，每学期开课的时候最好把任务高峰期（DDL）岔开（这学期一个周一，一个周二，emmmm）。否则一周总会有两天在疯狂熬夜。

3. 第一单元从a+b到正则+多项式的跨度稍大。可以把很多语言相关的练习，正则相关的练习放到开课前的假期来做。

4. JML和UML这两部分，感觉建模层面的工作可以多点。结果UML单元的任务是解析UML，并且很大精力花在读指导书上，就有点懵。