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