「BUAA OO」第四单元总结

本篇博客记录了笔者面向对象编程第四单元的学习过程与思考，以及对本课程四个单元学习的总结（源码与指导书可以参考Github）

第十三次作业

题目要求实现一个能实现用户请求的图书馆系统。本单元代码作业简单、架构清晰、迭代量少，笔者在三次作业中均没有发现什么值得注意的问题。

类图

第十四次作业

类图

第十五次作业

类图

正向建模与开发

正向建模与开发是一种**“从无到有”**的、系统化的产品创造过程。它从最初的需求和概念出发，通过系统性的设计、建模、仿真和验证，最终制造出符合预期的产品。

正向建模是正向开发流程中的核心环节之一，指的是在产品尚未实际存在之前，依据其功能需求、性能指标和设计规则，在数字世界中构建其虚拟模型的过程。这个模型是产品的“数字蓝图”。在本单元中，这个和我们先画类图再编写代码是相吻合的。

而正向开发则是一个更宏观的概念，它涵盖了从市场调研、概念提出、设计、建模、测试、生产到最终交付的全过程。正向建模是正向开发流程中的一个关键技术手段。

在本单元的练习中，我们主要用到了三种UML建模语言，分别是类图、状态图和顺序图

类图

类图会描述系统的静态结构。它告诉你系统里有什么（类），它们各自的属性和行为是什么，以及它们之间有什么样的静态关系。它是UML中最核心、最基础的图之一，也是面向对象编程的直接体现。它展示了系统的静态蓝图。

在正向建模的初期，当我们通过需求分析知道了系统的需求之后，首先就要用类图来搭建系统的核心结构。在正向建模中，类图是第一个、也是最重要的产出物。

状态图

状态图，也叫状态机图，用来描述一个对象的生命周期。它告诉你一个对象从创建到销毁会经历哪些状态，以及是什么事件触发了状态的改变。状态图专注于描述单个对象在其生命周期中可能经历的各种状态，以及如何从一个状态转换到另一个状态。

当系统的静态骨架（类图）搭建好后，我们会发现有些对象（类）的行为非常复杂，它在不同时间会表现出完全不同的行为。这时就需要状态图。在正向建模中，状态图是对类图的深化和补充，确保项目能够在各种内外环境下安全、正确的运行。

顺序图

顺序图，也叫时序图，用来描述对象之间的动态交互。它告诉你为了完成某个特定功能，不同对象之间是如何按时间顺序发送和接收消息的。顺序图是一种交互图。它通过描绘对象之间发送消息的时间顺序来显示多个对象之间的动态协作。

在正向建模中，顺序图是确保系统动态行为正确性的关键工具。它模拟了真实场景下各个部分是如何协作，以完成一个特定任务的。

保证三种图的一致性

在正向建模和整个软件开发生命周期中，保持类图、状态图和顺序图之间的一致性至关重要。如果它们之间出现矛盾，整个设计模型就会失去意义，甚至会误导后续的开发工作。三种图从不同视角描述同一个系统，如果它们的信息不一致，说明设计本身存在逻辑矛盾和缺陷。

大模型的辅助使用

大模型并非能够“自动”完成从建模到实现所有任务的黑盒。在建模、实现过程中，大模型应当更类似于“导航”系统的角色。要引导它在复杂场景中完成高质量的架构设计，关键在于设计师的主导作用和一套系统化的引导策略。

荣老师说，“要去拥抱新技术”。大模型的到来并不是一件灾难性的事情，但这也并不意味着我们可以完全依赖大模型。目前的大模型依然存在很多缺点，它拥有全面的资料，却不一定能够全部理解它们。笔者总结了一些大模型的引导方法：

上下文精确注入：为模型设定“设计边界”
大模型本身缺乏真实世界的项目背景。若是直接让其设计一个项目，其答案会因泛泛而谈而毫无价值。因此，第一步必须是为其构建一个精确的环境，比如赋予大模型一个身份，抑或是明确业务需求与约束、技术栈、设计模式等等。
任务分解与迭代式生成：将“大问题”拆解为“小步骤”
面对复杂架构，不能指望一步到位，需要逐层下降，引导模型分层、分步地思考。这种分解式的引导，本质上是模拟了我们课程中所学的正向建模流程，确保了设计的系统性和逻辑性。
批判性思维与一致性校验：从“全盘接收”到“审慎质询”
大模型最致命的弱点是“一本正经的胡说八道”。它缺乏对设计一致性的自我审查能力。程序员的批判性思维是不可或缺的一环。
面对大模型给出的答案，我们多问“为什么”，多去和真实情景对比、质询，而不是一抄了事。定义问题、进行关键决策、保证设计完整性和一致性的核心职责，始终应当掌握在人类设计师手中。

总结四个单元

架构设计思维的演进

四个单元一路肘来，收获还是很不少的。第一单元吃了一个大亏，之后再也不敢在架构设计上怠慢了。自第一单元后，再也没出现过架构导致的 WRONG ANSWER 问题。

当时第一单元的第二次作业，对封装的理解尚且不彻底，在递推函数的解析上面吃了很大的亏。后来渐渐理解到封装的含义，把任务下放给每个类，宏观上只管调用并信任类给出的方法，这是第一单元的“递归下降”里最重要的知识。

自此以后，笔者也打消了“绝不重构”的念头，每次写作业，尽量做到架构上的清晰简洁、可维护性好、可扩展性好。在后几个单元里都做得比较理想。

架构设计是很重要的，一个好的架构能让任务的完成更清晰、思路明确，能让程序员更容易理解代码的逻辑。无论是维护、扩展、测试都会有一个好的导向。

测试思维的演进

第一单元的时候还不会写评测机，当时也吃了不少亏。捏测试点的时候感觉很有自信，把好多情况都考虑了，其实想到的根本不全面。当时也只会黑盒测试。如果当时懂得代码走查的重要性的话，一定是能感觉到递推函数内部逻辑解析有情况遗漏的。

第二单元，一方面开始训练自己代码走查的能力，另一方面开始学会搭建评测机了。当时使用代码走查看出自己代码很多线程不安全的地方，在互测里也看到房友代码上的缺点，捏造测试点成功hack了，也是当时房间里唯一hack的人。另一方面，评测机搭建的强度也很高。关于数据生成，我才用了很多策略来提高数据点的强度，又设置了很多限制来保证数据点的正确性与有效性。最后就是正确性判定方面，我先是自己多思考、多判断，然后又根据大模型的辅助，提高正确性判定的严密性，最后也是在第二单元打出了很不错的成绩。

在这之后，对代码进行测试的时候就很灵活了。

课程收获

OO 的路已经告一段落了。到了这个份上，好像说不出什么特别有大道理的话。硬要说，笔者的收获更多还不是知识层面的。

刚开始接触的时候还是比较忐忑的，第一单元，对面向对象的思路还不是特别清晰。刚开始拿到作业要求的时候还不知道要从哪方面下手，看了好多博客才渐渐的有了思路。当时确实不会设计架构，现在反过来看第一单元三次作业的代码都感觉是~~屎山中的屎山~~。

但随着慢慢的接触，设计架构越来越得心应手了。对往届学长学姐的博客参考也少了很多，逐渐学会了在拿到要求之后先自己思考、设计，最后完成比较全面的、优良的项目。

面向对象是个值得深入研究的课题。大一只学过C语言的面向过程，刚接触到面向对象的时候是比较诧异的，“哇，代码还能这么写”（上完OOpre和舍友聊天的原话）。比如，封装的意识是面向过程编程体会不到的，就好比面对一个机器，你让它干什么它就干什么，但你从外部是无法得知它是如何实现的，看不到内部的状态，这种感觉真的好生奇妙。这样既提高了安全性，也降低了复杂度。

OO 的过程中有过喜悦，有过难过。在 OO 的路上，结识了很多友好的同学和助教，也犯过错误，认识到不足并改正。OO 课程陪伴了我们一个学期，给我们带来了极多截然不同的体验，~~想必我这辈子都忘不了你了~~。

衷心祝愿 OO 课能够越办越好，也希望自己能够当选 OO 助教，再和 OO 一起走一年！