2026年面向对象设计与构造课程全阶段总结

梁家诚-74056202 2026-06-21 23:26:16

一、第四单元：正向建模与开发实践总结

1.1 正向建模与开发体会

在第四单元里，我最深刻的体会就是“先设计再写代码”的威力。以前写前几个单元作业时，往往是拿到指导书就迫不及待地在IDEA里敲代码，结果总是边写边改，最后代码乱成一团。这个单元要求我们先画UML图（类图、状态图、顺序图），明确了每个类的职责和它们之间的调用关系后，再去写Java代码。这种正向建模的流程虽然在前期画图时比较费脑筋，但真正写代码时顺畅了很多，少走了很多重构的弯路。

1.2 两阶类图在正向建模过程中的作用

在这个过程中，两阶类图帮了我很大的忙：

概念类图阶段：这时候不需要考虑具体的代码细节，比如用什么集合、怎么写Getter和Setter。我只需要对照指导书，把里面提到的核心概念抽象成一个个类，并理清它们是谁包含谁、谁继承谁。这帮我从宏观上把握了整个作业的结构。
实现类图阶段：在概念类的基础上，我开始考虑具体的实现。比如把一对多的关系落实为具体的HashMap，定好方法的参数和返回值类型。
核心作用：这两阶类图就像是设计图纸，从粗到细，让我在动手敲代码之前就已经对整个系统的架构心里有底了，避免了直接写代码时顾此失彼的情况。

二、第四单元架构设计与模型-代码追踪关系分析

2.1 最终作业架构设计

我第四单元的最终架构主要分成了三个层次：

数据模型层：用来封装UML的各种元素，比如我自己写了MyClass和MyStateMachine等类，用来存下解析出来的基础信息。
解析与构建层：负责把输入的一大串元素分门别类地放进对应的容器里，理清它们之间的引用关系。
算法与检验层：这是本单元的核心。我用了深度优先搜索和广度优先搜索等图算法，去检查类图里有没有循环继承、有没有重复属性，以及状态图里状态是否可达。

2.2 代码设计与UML模型设计之间的追踪关系

在写完代码后，我对比了我的代码和最初设计的UML模型：

一致性：绝大多数的类和属性都能完美对应上。UML图里的每一个类，在我的代码里都有一个同名的Java类；图里的关联关系，在代码里就对应着成员变量。
迭代与修正：当然，设计和实际写代码还是有出入的。在实际敲代码和写测试时，我发现之前设计的某些类和调用关系有点冗余（比如对变量管理和词法解析的处理）。我修改了代码，把多余的代码删掉，理清了边界，并且回过头去把UML图也同步更新了。这让我意识到，模型和代码并不是一成不变的，而是在开发过程中互相验证、一起完善的。

三、大模型辅助正向建模的体验与提示词工程总结

这个单元我们也尝试了用大模型来辅助写代码和设计架构，体验很新鲜，也踩了一些坑。

3.1 如何引导大模型完成复杂的架构设计

如果直接把长长的指导书甩给大模型，让它“帮我写个架构”，它吐出来的代码通常漏洞百出，根本没法用。后来我调整了策略，发现必须一步步去引导它：

明确角色和规则：先告诉它它现在是一个严谨的Java架构师，然后把这一单元最核心的限制条件喂给它。
拆分任务：不让它一次性把代码写完。我先让它根据需求帮我列出应该设计哪些类，等我觉得这个结构合理了，再让它帮我设计某个具体类的方法签名。
严格限制输出：在提问时要明确告诉它不要写冗余的代码，并且要注意判空处理和代码规范。通过这种一步步的提示，大模型给出的架构建议才慢慢变得靠谱起来。

四、四个单元中架构设计思维的演进

回想这学期做过的所有OO作业，我感觉自己的设计思维发生了一场蜕变：

第一单元（表达式作业）：刚开始学OO，满脑子其实还是面向过程的思维。虽然名义上建了多项式类、项类、因子类，但实际上就是在想怎么把字符串给拆开、怎么算出来。类和类之间互相调用，耦合度特别高，代码写得非常痛苦。
第二单元（电梯作业）：这个单元引入了多线程并发，我的思维被迫从静态的数据结构转到了动态的线程交互上。为了不让电梯死锁、为了保证线程安全，我学着去用生产者-消费者模式，设计了专门的等待队列来共享数据。这时候我开始意识到“高内聚低耦合”不仅是口号，而是不翻车的保障。
第三单元（JML作业）：这个单元是契约导向。指导书把每个方法要做什么用数学规格写得清清楚楚。我的精力从“怎么设计架构”变成了“如何在满足契约的前提下提高性能”。为了不强测超时，我学着在架构里引入并查集、堆优化等高效的图算法。
第四单元（UML作业）：到了最后一个单元，前面的知识好像串起来了。我不再是盲目地去堆砌功能，而是学会了先从全局的结构、状态和交互去规划整个系统，真正建立起了先整体后局部、先设计后编码的软件工程思维。

五、四个单元中测试思维的演进

互测和强测让我深刻明白，写完代码只是完成了一半，测试才是确保不挂科的关键。我的测试思维也在不断升级：

第一单元：那时候测试方法很原始，就是自己手动编几个边界数据。比如测个0、测个负数、或者套好几层括号的极长表达式。这种纯手动的黑盒测试很容易漏掉Bug。
第二单元：电梯作业因为有多线程，每次运行的结果可能都不一样，手动测根本测不出死锁。于是我跟着同学学，第一次搭建了自动化的评测机。投喂大量的随机请求，并和其他同学的代码进行对拍。这个单元让我学会了用自动化和大规模对拍来抓随机Bug。
第三单元：因为有JML规格，测试变成了白盒测试。我开始使用JUnit针对每一个方法进行单元测试，严格对照规格里的条件，逐条检查代码的分支是否都覆盖到了，确保逻辑上没有任何死角。
第四单元：到了UML单元，测试的重点变成了对复杂图结构的验证。为了测试代码的鲁棒性，我开始故意去构造一些奇奇怪怪的、不符合规范的非法输入（也就是Hack数据），看看代码会不会崩溃。这时候的测试思维已经变成了主动去寻找系统的边界和漏洞。