# OO第四单元总结

肖杰方-24371471 2026-06-19 22:50:21

类图与建模

第一阶类图的主要作用是搭建一个大致的框架，我们通过分析题目的具体要求，提炼出所需的类以及各个类应当具备的方法，确定每个方法需要用到的属性，并将属性加入到类中。这一步并不要求完善，只需要做到能体现整体思路就行。在后续实现代码的过程中，我们可以根据这一份思路来展开，如果遇到了缺少的内容，或者冗余的属性与方法，完全可以在实现的过程中动态地修改我们的类图。

第二阶类图也就是我们修改完善之后的类图，它不再主要承担前期探索作用，而是用于记录、验证和复盘最终设计，主要在于与第一阶段类图进行对比，通过比较我们可以明确自己在实现的过程中进行了哪些修改，如果这些修改是建模时考虑不当，我们可以总结经验，在后续的过程中改善自己的建模能力。如果是实现过程中忽略了某些条件，我们就需要回溯问题产生的原因，并修改代码，把自己的代码改回正确的版本。

架构设计

我的架构十分简单，一共只有8个类，也就是MainClass，Library，User，Book，Bookshelf， Return，Readroom，Appointroom。Library 负责整体业务流程的编排，其他类负责封装各自的状态和局部业务规则，并通过接口与 Library 协作。

最终我的代码与UML图的关联十分紧密，因为我一般都会先确保自己的设计基本可行再去动笔，少数差异主要体现在某些类内部的辅助方法。

大模型与建模

我从第一单元开始就尝试了让大模型辅助建模，值得注意的是，当问题非常复杂的时候，大模型会出现一定程度上的纰漏，所以最主要的工作还是由我们自己来完成。

根据经验，我们可以把建模的工作分为以下几个步骤：

首先，我们整体阅读一遍题目的具体要求，自己提炼出整个项目所需的类，并明确每个类承担的责任，类与类之间需要怎么合作。比如在第二单元的电梯调度中，调度器、电梯仓和电梯之间的合作关系，必须先想清楚。

其次，我们把自己的思路转述给大模型，让大模型理解我们的思路，根据大模型反馈的意见进行修改。如果我们与大模型的意见一致，就可以开始对类的具体内容进行设计。我们明确每个类需要暴露的接口，确认这些接口会被什么类使用。

最后，我们可以利用大模型的记忆能力，让它汇总讨论的结果，生成一份任务清单，方便我们在后续的代码实现中逐步进行。生成清单之后我们还要简单地检查一遍，确保任务要求被完整地覆盖，如果存在问题，我们需要及时质询大模型并加以修改，如果这样宏观的问题被遗漏，后续的修改将十分困难。

至于具体的算法选择，我们完全可以在实现对应接口的时候再去讨论，主要遵循聚焦的原则，让大模型和程序员本身一次只干一件事。

思维演进

（1）有关架构

在前两次作业中，我非常喜欢一开始就针对某个问题展开具体的讨论，先解决整道题中的某个具体问题再去宏观地设计。这非常不利于大模型辅助建模，他们可能会产生混乱，在后续的交流中混淆某些相似的问题，以致于前后内容不对应，我们很难得到一个清晰完整的答案。

所以在后续两次的任务中，我都会先明确一个宏观的目标与架构，根据这个最高层次的抽象来往下方延伸，遇到具体的问题再进一步分析。

（2）有关测试

从一开始，我就学会了用AI构建评测机来辅助测试，评测机由 runner、checker、generator 和 main 四个部分组成，分别负责跑程序、对拍程序、生成数据与总体协调。其中最为关键的就是数据生成器，一个好的生成器不仅可以对程序进行压力测试，还可以覆盖一些极端情况。所以我们不能仅仅依赖于随机数，还要自行思考一些极端数据，把这些极端数据作为特殊样例放在数据生成器里面。

课程收获

这个学期的OO课程中，我熟悉了面向对象语言中“多态”，“封装”和“继承”这三个概念，也学会了如何处理多线程问题。在学习的后期，还了解了UML和JML这两种规格化语言。但是这些都属于技术层面的内容，对于以后的意义不大，关键在于我通过实践增强了自己的架构设计能力，并且对面向对象思维有了一个新的认识。

我们需要认识到，面向对象编程不过是与面向过程编程并列的一种编程范式，本身没有什么高级的地方。它更贴近生活，更加符合人类的思维，它通过抽象和封装提升了代码的可维护性，但如果设计层次过多，也可能在部分性能敏感的场景中引入额外开销。我们需要学会的，便是在两种编程思维之间灵活切换，比如在基本的算法设计与代码实现中利用过程性的思维提升自己的代码性能，在复杂系统的整体架构设计中利用面向对象的思维层层解剖，让代码更加清晰。这就够了。

课程心得

不知从何时起，“面向对象编程”这个词便带着一抹神秘而迷人的色彩，引人无限神往。上学期，我们通过Java语言初窥门径；而这个学期，我们终于在正式的OO课堂中，与这一独特的编程思想来了一场短兵相接的浪漫邂逅。

对于外行人而言，“面向对象”中最具诱惑力的字眼，莫过于“对象”。虽然这门课程最终未能帮我斩获爱情，但它却用极其硬核的方式，让我完整体味了追寻一个“对象”所要历经的起承转合。

在“表达式解析”与“电梯单元”中，我曾怀揣着极大的热忱，渴望与屏幕上的代码共舞。仍记得三四月份的每个周六，在三教的一隅，我一坐便是七八个小时。从架构的勾勒到代码的雕琢，我不断地与Gemini“深度对齐”（甚至伴随着些许情绪化的沟通），只为让我的代码呈现出最完美的姿态——逻辑必须严密，性能必须卓越，风格必须优雅。作为这段废寝忘食岁月的见证，我的体重也极其尊贵地从72kg飙升至77kg，这也算是一种另类的“厚积薄发”吧。

可惜，纯粹的激情往往难逃边际效应递减的宿命。当迷雾散去，曾经令人神往的“对象”也一度变得面目可憎。JML单元充斥着冗杂晦涩的谓词结构，如同天书；随后的UML单元亦是按部就班，缺乏美感。我并非对架构设计失去了耐心，我只是本能地抗拒那些冰冷的条条框框。然而静心思之，这些规则绝非为了制造阻碍，其本质是为了实现“高效的沟通”。遗憾的是，目前的课程尚缺乏团队协作的舞台，导致这些规则的光芒被暂时湮灭，只留下了形式上的臃肿。如果明年有机会，或许助教团队可以引入团队合作的环节，唯有在真正的协作中，规格化的巨大魅力才能真正绽放。

在历经了狂热的追求与疲惫的倦怠后，面向对象编程的真实容颜终于如水落石出般展现在我们面前。她并不特别，无需被奉上神坛，她只是与“面向过程”并肩而立的一种思想；但她也绝不乏味，她拥有着一种朴素而轻盈的美——她更拟真，更清爽，对开发者更具同理心。

在这门课程中，我们学会的最珍贵的一课，便是如何与她自如地相处。以一个普通人的视界，我们应当在需要时敏锐地唤醒她，也应当在不适用时决绝地放手。至于未来的代码之路上还有多少风浪？那是以后的事。至少此刻，我们已然穿过风暴，看见了风景。谢谢大家。

...全文