BUAA-OO-UML
作业架构设计分析
第一次作业
类图如下：
这个架构十分简明，就是在底层数据和调用者之间建立起一层隔离层。但其实可以将转换过程延迟到调用阶段。
第二次作业
类图如下：
架构基本同上。
心得体会
为什么要 OOP
最早的 OOP 语言是 Simula，意为“模拟系统”。当需要模拟系统时，我们可以这样考虑：对于系统中的每个对象，都构造一个与之对应的计算对象；对于系统中的每种活动，都定义一个与之对应的计算过程；整个系统分成可以相互协作的几个部分，每个部分继续细分成多个小部分，依次类推；每个部分都具有其独立性，不同的部分不应该互相干涉。为了实现以上几点，我们有了抽象、有了消息传递、有了继承和多态、有了闭包，封装和隔离等等一系列的名词。这就是 OOP 所要表达的思想。
遵循 OOP 思想开发的软件，应是模块化的且各模块是具有内聚力的，否则将无法很好地去模拟一个系统。而正是这样的要求，使得其实易于维护的：需要扩充新对象或新活动时，或是需要进行修正时，只需在某个小局部进行修改就可以完成。因为它天然地模块化、天然地存在着抽象屏障。
OOP 是好东西。
OOP 是必要的吗
虽然 OOP 是好，但并不适合所有场景。写 GUI、OS，这当然是十分适合的，但如果是表达式解析这种数据和操作不是捆绑在一起的场景，就很难受了。
而且 OOP 并不是那么容易就能实现的。总的来说，两点，抽象和封装。前者要使得某个“类”的所有子类都能被一视同仁地对待，后者要使得某个“类”的外延尽可能地小的同时满足所有可能的要求。并不是用了支持 OOP 表达的语言就是 OOP，该恶心的还是恶心。
归根到底，我们的目标都是使得软件易于开发、易于维护，也就是降低软件开发复杂度，是否采取 OOP 与目标的实现并无相悖之处。解决问题才是关键，唯 OOP 论只会显得可笑。
建议
- 这门课可以考虑写一个逐步开发的 OS
- 可以考虑换教学语言，譬如 Erlang, Scheme 之类的
- 引入 JML 非常好，但是工具链不齐全，隔壁的 C++20 都有语言标准层面上的 Contract 了。如果还想继续使用 JML，至少得弄一套完整可用的工具链供学生使用，或者增加限制减少语言特性以免工具链不支持