第四单元和课程总结：简单的架构设计意识

一、第四单元架构设计总结

第一次作业
- 由于需要按名查找类图模型，于是建立"Class"类进行管理
- 由于方法具有参数导致类中存在二级结构，于是建立"Operation"类进行管理，再将其作为Class类的成员
- 对重名情况的处理：
  不同对象的ID不同，对象实体也不同，但Name(String)相同，这是一个相当常见的场景。
  笔者采用以下方法进行处理：
  - 建立从ID到对象的映射： private HashMap<String, Class> idsToClass
    这样的映射是一一映射，使用普通的HashMap即可实现。
  - 建立从Name到ID的映射： private MultiHashMap<String, String> nameToIds
    这样的映射是一对多的映射，使用自建数据结构MultiHashMap实现。
  - MultiHashMap的形式： HashMap<K, HashSet<V>> multiMap;
    通过Key可以查询到一个包含Value的HashSet。这样就实现了一对多映射的方便管理。
  - 可以预见到的是，自己建立一个 HashMap<K, HashSet<V>> multiMap 是十分方便的，其使用场景非常普遍，在两次作业中具体有：
    - 维护一对多的映射（例如，通过重复的Name查询独一无二的ID，抛出DuplicateClassNameException等）
    - 维护简单图的邻接表结构（一个点的邻接点或关联边构成一个集合）
- 由于输入的元素类型顺序不定，于是构造UmlComparator类实现Comparator接口，用于对元素进行排序，
  要求任意元素的父元素出现顺序在其之前： Arrays.sort(elements, new UmlComparator());
- 具体架构大意如下类图：
第二次作业：
- 继承了第一次作业的类图解析与处理架构
- 由于需要按名查找状态机模型，于是建立"StateMachine"类进行管理
- 由于要求撰写类实现General接口，但是类不支持多继承，所以为了实现类图维护与有效性检查、顺序图维护、状态图维护这三个完全独立的功能，
  将三个独立的功能分散到三个不同的类中，再将它们组合到最终的目标类中（将他们实例化，作为成员）。构造时将元素同时传给三个类进行构造即可。
  这样，最终要求的目标类就仅剩对三个类中方法的调用，十分简洁，且三个功能互不干扰。
  同时，对源码结构的管理也变得十分简洁，如下图所示：
- 具体架构大意如下类间关系图：

二、课程中对架构设计及OO理解的演进

第一单元
- 应当具有好的可拓展性，不应在方法中做出太多基于当前假设的妥协
- 应当将方法分解为基本原子操作的组合，让方法各司其职，而不是出现：
  - 方法间的功能重合
  - 迭代时的方法内容手动拆分
  - 方法的副作用大，内容包含与其名称不符的额外操作
  - 某方法中接了本来应该在上层方法中进行逻辑判断的锅
- 准确识别继承和接口的使用时机
  - 当且仅当确实有可抽象的共性内容和提取的必要时，才进行继承和接口操作
  - 善用工厂模式系列和单例模式
  - 在最初设计时留出进行可拓展的空间，该空间很大程度由类间关系的设计决定
- 架构设计应当给性能的优化留出空间，如将需要算法的操作放在某个方法中，并将其尽量与其他方法解耦，便于后续进行调整
  - 典型例子：给定图，求最短路、联通块等
  - 不应进行重复性的工作，应借助程序员理清逻辑和过程、finished标记、lazy等方法提高性能
第二单元
- 在多线程程序中，应当将同步执行区域的代码和直接调用的代码区分开，放进不同的类中（如：调度器被电梯线程直接调用代码，没有必要设置成一个线程）
- 尽量少使用线程，准确识别什么对象应该单独承载一个线程（如：每部电梯一个线程，还是每个请求一个线程）
- 可以在设计时和编码中使用UML顺序图对每个线程间的交互和线程的进展进行设计
第三单元和第四单元
- 尽量识别出可抽象的、共有的功能或数据结构，单独建立一个类进行管理，并进行有效复用，如：
  - 第四单元的MultiHashMap类，既能维护图结构，又能完成一对多的映射，做到了高效的复用
  - 第三单元的ShortestPath类和Connectivity类，配合Graph类分别进行运算，在主类看来就成为了一个完成特定功能而无需关心的工具黑箱
- 完全无关的功能，应该由完全独立的类（甚至是package）实现，再在主逻辑类中进行组合，尽量将核心功能下放
- UML图是一种辅助设计的好的工具，不仅仅是类图，其顺序图和状态图对于程序员也十分重要：
  - 状态图在设计和编码过程中是极其重要的逻辑指导
  - 顺序图在多线程程序设计中具有十分重要的意义

三、课程中对测试的理解与实践的演进

第一单元：对于简单的输入-输出型程序：

具有固定格式的：使用数据生成器进行批量数据生成和测试
具有大量分支的：首先总结出每个分支处的组合情况，然后在数据生成器和手造数据中确保覆盖每种情况
首先使用数据生成器等技巧覆盖大部分的情况，然后针对其求补集，人工构造小规模但刁钻的数据进行进一步的确保

第二单元：对于交互输入和多线程程序

使用定时投喂模拟器，在关键的时间节点（如上一条请求刚刚处理完、刚刚开始处理等）附近投喂交互性的输入数据进行测试
构造数据规模不大但对同步互斥性、线程协作要求高的数据，进行反复多次测试，尽量降低不可复现bug的可能性

第三单元：
- 使用JUnit对每个类的每个方法进行单元测试，首先尽量保证每个方法内部的正确性
- 使用简单的类似JML的语言（自然语言和Java相结合的方式笔者觉得较好）对方法、类和数据进行规范
- 在JUnit的过程中，根据上述的规范语言构造针对性的测试用例

四、课程收获

Java程序设计
- 基础语言
- 高级
  - Junit与单元测试
  - 并发、多线程编程
面向对象设计
- 继承与接口的类间关系设计
- 好的设计模式及其应用场景
- 第一次进行系统的面向对象程序实践
- 不断丰富需求下的程序重构与迭代
- UML类图、协作图、状态图的应用
Generally程序设计
- 契约式程序设计与JML类似物
- 单元测试

五、关于课程的三个具体建议

放弃对JML的强制语法要求和基于JML自动生成JUnit测试，但保留前置条件、后置条件等说明。
即，不要求求出绝对正确的JML语言，也不要求使用OpenJML等工具对程序进行验证和测试。（由于其工具链并不完善）
但，保留PRE-condition、POST-condition等的撰写和阅读要求，它们是十分重要的。
表意明确是最重要的，是不是精确使用JML并不是那么重要。即使是自然语言+Java的组合，只要能达到目的也一样好。
不应该为了形式而忘了其最初的目的。
第三单元和第四单元的讲授重点是JML和UML，作业的考察重点却是类似于第一单元的简单面向对象程序设计，作业意义不大。
可以将某一单元的内容改为复杂的面向对象设计，如应用复杂的设计模式等。
在第一单元中，课程组鼓励大家使用更为先进的设计模式，但没有硬性要求。
在后续的单元中，应该对其加大训练力度，否则其训练强度不够，难以过渡到实际开发中的复杂场景要求。
实验课的进一步科学化。
目前的实验课有如下几个问题：
(1) 题面的说明不够精确、严谨。（如多线程的某次实验，代码中和题面中提到的输出内容完全不符，严重影响自动测评的正确性）
(2) 评分标准模糊，评分手段不够严谨。（如许多代码题却无法进行有效的自动测评，只能由人工测试。如JML的补充等。）
(3) 上午讲完下午考，不够熟悉。