全部
作业
作业提交
活动专区

2025年OO课程总结

庞济慷-23371214 2025-06-13 01:04:55

2025 OO课程总结

Unit4单元总结

从蓝图到代码：图书管理系统建模与架构设计反思

构建软件很像建造一座大楼。你不能直接随心所欲地堆砌砖块，而是需要从一张蓝图开始。在软件工程中，这种“绘制蓝图”的过程被称为建模。本单元的作业——一个功能完善的图书管理系统——是实践正向建模的绝佳案例。正向建模指的是将需求转化为概念模型（如UML图），然后系统地将该模型开发为可用代码的过程。本文将反思这一开发历程、最终成形的系统架构，以及我们该如何引导强大的人工智能（AI）工具来辅助我们完成这类复杂的设计任务。

1. 建模实践：正向开发方法

正向建模的核心是从零开始，自下而上地构建。我们从现实世界的概念出发，将它们直接映射为软件组件。对于这个图书管理系统，这意味着首先要识别出核心实体：

书籍 (Book)：每本书有唯一的ID、所处的状态（在书架上还是被借出？）、以及一系列的流转记录。
用户 (Person)：每个用户有学号、信用分，并且可以借阅、预约或在阅览室读书。
图书馆 (Library)：作为所有事物的容器，它负责管理书籍在不同“地点”的流转和所有相关的规则。

我们没有创建一个包罗万象、难以维护的巨型类，而是将复杂的系统拆分成了符合现实逻辑的“地点”或“部门”。这一点在最终的代码中得到了清晰的体现，例如以下这些类：

BookShelf (书架)
HotBookshelf (热门书架)
Reservation (预约处)
CirculationDesk (借还处)
ReadingRoom (阅览室)

这种面向对象的方法使得整个系统非常直观。当一本书被归还时，它会逻辑清晰地进入 CirculationDesk。当一本被预约的书有库存时，它会从 BookShelf 移动到 Reservation 区域。这种从概念模型到代码类的直接映射，使得系统更容易被理解、调试和扩展。

2. 架构深潜：从蓝图到现实

本系统的最终架构清晰而高效，严格遵循了优秀的面向对象设计原则。

系统架构

该系统的架构以 Library 类为核心，它扮演着外观模式 (Facade) 的角色。它为外部调用（例如 Runner 类）提供了一个简单、统一的接口，而无需关心其内部子系统的复杂性。Runner 类只需要告诉 Library 它想做什么（例如，library.borrowBook(...)），Library 类便会将请求委派给合适的内部组件（如 BookShelf 或 HotBookshelf）去处理。

各个类之间的关系非常明确：

组合 (Composition)：Library 类由 BookShelf、Reservation、CirculationDesk、ReadingRoom 和 HotBookshelf 组成。这些组件的存在依赖于图书馆。
数据模型 (Data Models)：Book 和 Person 类作为富含数据的模型，在系统的不同组件之间传递。
控制器 (Controller)：Runner 类作为主控制器，处理用户输入并按天驱动整个模拟的运行。

3. 驾驭AI：复杂场景下的架构设计指南

利用大型语言模型（LLM）来辅助这种正向建模过程可以发挥巨大的威力，但这并非魔法。你不能简单地对AI说：“给我构建一个图书管理系统。” AI是一个工具，和所有高级工具一样，它需要一个熟练的操作者来提供清晰、准确的指令。

基于本次实践经验，以下是关于如何有效引导AI进行复杂系统设计的几点总结：

从“做什么”开始 (明确需求与约束):

向AI提供完整的上下文，不要含糊其辞。不要只说“一本书可以被借阅”，而是要明确规则：

“一个学生只有在未持有其他B类书籍时才能借阅一本B类书。只有在未持有相同ISBN号的C类书时，才能借阅一本C类书。如果信用分低于60，则无法借书。”

定义“怎么做” (明确交互与模式):

提出一个高层级的架构设想。你可以通过指定设计模式来引导AI的设计方向。

“请使用外观模式来设计主要的 Library 类，用它处理所有用户请求。Library 类内部应包含代表不同物理位置的对象，例如 BookShelf 和 ReadingRoom。”

迭代式工作并要求优化:

不要指望一次性获得整个系统。需要分步骤、分模块地进行构建。

例如：

你：“请为 Book 和 Person 生成基础的类结构。”
AI：（生成基础类）
你：“很好。现在，请修改 Book 类，使其能够记录其状态变更的历史。历史中的每个条目都应包含日期、变更前的状态和变更后的状态。”
AI：（为 Book 类添加 traces ArrayList）
要求解释以确保正确性:

要求AI解释其设计选择。这有助于我们发现逻辑错误或低效的设计。

你：“对于 BookShelf，你选择了 HashMap<LibraryBookIsbn, ArrayDeque<LibraryBookId>> 这种数据结构。为什么是这个特定的组合？”

理想的AI回答：“我选择 HashMap 是因为它在按ISBN查找书籍时具有O(1)的平均时间复杂度。值的部分是一个 ArrayDeque（作为队列使用），因为它能高效地处理‘先进先出’的借阅逻辑，即同一ISBN的任意一本可用副本都可以被借出。”

通过遵循这种结构化、迭代式和探究式的沟通方法，我们可以将AI从一个简单的代码生成器转变为一个强大的架构设计伙伴，帮助我们更高效地构建出健壮且模型优良的系统。

本学科OO课程总结

在一个学期的面向对象课程中，我经历了四个充满挑战与收获的单元。从最初的算法解析到最后的系统开发，这不仅是知识的积累，更是我架构设计思维与测试思维不断演进的历程。

架构设计思维的演进

我的架构设计思维，在四个单元中呈现出从“单点突破”到“系统集成”的渐进式发展。

单元一：梯度下降法解析表达式

这个单元让我初次体验到面向对象的魅力，即如何将复杂的数学问题抽象为对象，并运用其特性解决问题。我的架构思考主要集中在如何高效地实现算法本身，关注表达式的解析、求导以及迭代过程中的数据管理。此时，架构设计更侧重于算法的清晰表达和计算效率，尚未涉及复杂的模块间协作。我开始尝试将不同的数学操作封装成独立的类，如“表达式”、“变量”等，这为后续更复杂的系统设计打下了基础。

单元二：多线程电梯调度与“影子电梯”

这是我架构思维的第一次飞跃。面对电梯调度这样一个复杂的并发问题，我开始思考如何将并发逻辑与业务逻辑分离。为了优化调度，我引入了“影子电梯”的概念，这本身就是一种架构上的创新——通过引入一个虚拟实体来辅助决策。我的重心放在如何合理地划分线程，确保数据的共享与隔离。然而，对多线程锁的运用不够熟练，导致死锁和忙等问题，也暴露了我对并发架构的理解还不够深入。这让我意识到，架构设计不仅要考虑功能的实现，更要关注系统的健壮性、并发性和资源管理。

单元三：JML规格与性能优化

这个单元让我深刻理解了契约式设计的重要性。JML规范迫使我从系统行为的外部视角去思考设计，而不是简单地堆砌代码。我开始关注接口设计、方法的前置条件与后置条件，以及不变式的维护。在性能优化方面，我开始审视数据结构的选择，例如如何优化查询性能，从而减少不必要的计算。这促使我从更宏观的层面考虑模块的职责与交互，并在此基础上进行精细化的性能调优。架构设计不再是简单的功能实现，而是严谨的规格遵循与高效的资源利用。

单元四：图书馆管理系统

这个单元是前三个单元知识的集大成者，也是我架构思维的真正成熟。我从零开始进行正向建模与开发，全面思考了系统各个模块的划分（用户管理、书籍管理、借阅管理等）、类之间的关系（继承、聚合、关联），以及数据持久化的方式。我不再局限于单个算法或功能点，而是着眼于整个系统的可扩展性、可维护性和稳定性。这个过程让我体会到，一个好的架构设计是从需求出发，兼顾未来发展，并能有效指导代码实现的蓝图。

测试思维的演进

我的测试思维，也随着课程的深入，从最初的“功能验证”发展到“系统健壮性保障”。

单元一：梯度下降法解析表达式

在第一个单元，我的测试思维相对简单，主要停留在功能验证阶段。我会针对不同类型的表达式（例如多项式、三角函数）和不同的初始值进行测试，验证梯度下降算法能否正确收敛到最小值，以及解析结果是否符合预期。测试用例的设计更多是基于输入输出的覆盖，而较少关注边界条件和异常情况。

单元二：多线程电梯调度与“影子电梯”

这个单元让我认识到并发测试的复杂性。我开始意识到，仅仅测试单个线程的功能是远远不够的。我需要设计大量的并发测试用例，模拟多用户同时请求、电梯运行中途增减请求等场景。通过引入“影子电梯”来优化调度，我发现除了验证调度结果的正确性，还要关注多线程间的同步与通信问题。面对死锁和忙等，我开始使用日志记录、调试工具来追踪线程状态，尝试理解并发执行的路径。这促使我从随机测试和压力测试的角度去思考，尝试发现代码在极端并发条件下的行为。

单元三：JML规格与性能优化

JML的引入彻底改变了我的测试思路。我开始基于JML规格来设计测试用例，确保代码严格遵循前置条件、后置条件和不变式。这是一种从白盒测试向黑盒测试过渡的过程，我不再只关注代码逻辑，更注重规格的实现是否准确无误。在性能优化阶段，我开始引入性能测试，例如测试查询的响应时间、数据写入的吞吐量。这让我理解到，测试不仅要验证功能的正确性，还要评估系统的性能指标是否达到要求。我开始思考如何构造大规模数据来模拟真实场景，以验证优化的效果。