[BUAA-OO]第四单元总结

kk程序猿

已于 2024-06-10 21:46:55 修改

阅读量917

点赞数 11

分类专栏： OO 面向对象设计与构造 BUAA 文章标签： java

于 2024-06-10 21:22:59 首次发布

本文链接：https://blog.csdn.net/m0_73558835/article/details/139582444

版权

OO 同时被 3 个专栏收录

4 篇文章 0 订阅

订阅专栏

面向对象设计与构造

4 篇文章 0 订阅

订阅专栏

BUAA

4 篇文章 0 订阅

订阅专栏

前言

不知不觉来到OO课程的尾声啦，写这篇博客的时候正好是6.8号高考的第二天，竟让我想起来那年考完最后一科生物合上笔盖的那一瞬间。总之不管结果如何，我也算走过来了，在过程中学到了很多也收获到了很多。

正向建模与开发

在面向对象编程中，正向建模与开发是指从需求分析到系统实现的一种开发方法。它强调从问题域的角度出发，通过建立模型来描述系统的结构、行为和关系，并将这些模型转化为可执行的代码。

在本单元作业中，这个模型就是UML图。

正向建模与开发在工程领域有十分重要的作用：

**有助于团队协作开发。**UML提供了一种标准化的图形表示方法，使得系统设计和架构可以更容易被团队成员和利益相关者理解和沟通。它提供了一种通用的语言，帮助人们更好地理解和讨论系统的不同方面。这大大提高了团队工作的效率。虽然在本课程的个人任务中并没有体会到这一点，或许可以成为以后课程改革的方向？
**指导代码开发。**UML建模提供了对代码开发的指导，帮助开发人员更好地理解系统的结构和组织，并根据类图、状态图、顺序图等UML图表编写相应的代码。这有助于提高开发人员的效率和代码质量。这一点在本单元的任务中得到了充分体现。由于图书管理系统的庞大规模，如果直接上手进行代码编写，很可能会乱了手脚，制造出意想不到的bug，而UML图则给我们提供了一个非常直观的整体的架构说明，让我们可以在编写代码的时候参照UML图进行编写，大方向定了细节实现起来也就不难了。
**便于bug修复。**通过使用UML进行正向建模，可以在实际编码之前发现和解决潜在的设计问题。这可以降低开发过程中的风险，并减少后期修改的成本和工作量。我们可以对比修改前后的UML图发现新增或修改了哪些方法，这些方法可能会影响怎样的状态转移，与其他类有怎样的关联关系，从中我们可以更轻松的定位到bug产生的地方，进而修复。

总而言之，在面向对象编程中，正向建模与开发的思想可以很好的帮助编程者进行团队协作，高效且高质量地完成大型工程的开发。

本单元的类图、状态图、顺序图如下：
在这里插入图片描述

在这里插入图片描述

本单元的设计与架构

hw13

本次作业要求初步建立一个图书管理系统的框架，后续作业都在这个基础上进行小规模的功能扩充，因此第一次作业的架构至关重要，也是本单元三次作业中耗时最长的一次作业。

图书管理员类

本次作业的图书可能存在于四个位置，分别是读者处、书架处、借还处、预约处，这一点在状态图中有很直观的体现（UML图的好处这就体现出来了吧）。

最朴素的方法是在Library类中为这四个地方分别建立一个容器进行存储，并编写对应的方法进行管理，但这样会造成各个地方的数据和数据管理不够独立和明确，同时在后续功能增多的情况下很可能造成Library类的冗长。所以我采取为每个地方建立一个管理员类，负责对数据的存储和管理，这点也很容易由现实中的图书管理员而联想到。

容器选择

这次图书管理员处的存储图书的容器选择也是一个值得注意的点。

书架处shelf：有可能存储多种id的图书，并且每个图书可能有多个副本，因此书架处的图书是二元的元组，很容易想到用HashMap来进行管理，也能很大程度上加快查询的速度（但也需要注意边遍历边删除的方式）。
借还处broBooks：同书架一样的性质。
预约处aoBooks：根据要求，在存储图书的时候需要存储相应预约的人的id以及预约时间等其他数据，这明显不是简单的二元组了。但我们也可以使之成为类二元组，为了实现这一点，我编写了Book类和RegisterBook类，分别代表位于预约处的图书和预约成功还未送达的图书，前者需要有id,readerId,inDay(到达预约处日期)等成员变量，后者只需要有id,readerId的信息即可。因此我用HashMap<LibraryBookId,ArrayList<Book>>、HashMap<LibraryBookId,ArrayList<RegisterBook>>作为容器，很好的存储了所有需要的信息。
读者处haveBooks：读者处的书由于本次作业的限制，一个人不能拥有两本以上的同id的书，因此只需要用ArrayList存储图书的id即可，以后若有其他信息需要存储只需要用HashMap将LibraryBookId和相关信息进行绑定即可，可扩展性较强。

消息传递

当我们接收到一个指令时，我们该通过怎样的流程一步步传递给底层进行数据管理呢？顺序图就能很直观地反应这一流程（所以UML是非常好的！）。

拿图中所示的图书预约来说，首先Main接收到这个指令，将其发送给Library进行处理，这是因为Main只负责输入输出的功能，这也符合高内聚低耦合的思想。接着Library接收相应指令进一步下发给OrderLibrarian进行处理，这里Library更像是一个指挥官（图书馆的boss），OrderLibrarian负责新增预约请求，在闭馆后由Library读取预约请求进行图书的整理和转运，进而通知读者来取书，完成预约和拿取的过程。

hw14

本次作业新增图书漂流处、续借以及图书借阅期限的要求。

对于图书漂流处我们只需要新增一个管理图书漂流处的管理员类，并为其添加相应的容器和操作即可。对于续借和借阅期限的需求，我们则需要给Reader类加上有关于借阅时间的容器，并对其维护，这里我采取的是存储图书到达读者手上的时间（不太准确），当续借成功时相关的inDay进行相应的增加延长，作为我们判断是否延期的依据。

hw15

本次作业新增读者信用积分的概念。这次作业的功能实现十分简单，只需要在读者类新增一个成员变量credit，并在读者完成相应操作时增加或减少credit即可，并在进行一些操作时判断credit是否符合要求，若不符合则拒绝此次操作即可。本次作业十分善良，完成时间不到两个小时。

架构思维的演进

第一单元

第一单元主题是“表达式展开”，主要是想让我们初步体会面向对象的思想，体会层次化编程的好处。面向对象即一切皆是对象，从本单元作业就能很好的体现，从宏观来看多项式是对象，通过一个个单项式连接，单项式也是对象，单项式由一个个因子组成，因子也是对象，因子有很多不同的种类，这些不同种类的因子都是对象。因为刚开始接触oo，对面向对象的思维并不熟悉和掌握，因此我的第一次作业的耦合度是无法想象的，因此在看到第二次作业的要求的时候我就傻了眼，在挣扎一天一夜后不得已选择重构，这也是四个单元里我唯一进行重构的一次作业，但这也让我对层次化编程的重要性有了更深的认识——通过从问题中抽象出一系列对象，我们可以建立一个层次化、模块化的结构，从而降低了问题的复杂度。hw2重构之后，由于良好的架构，第三次作业也完成的十分迅速和得心应手。

第二单元

第二单元的主题是”电梯调度“，私以为是四个单元中难度的巅峰，要求我们掌握多线程的创建和维护，并警惕线程安全问题。在多线程的情境下，对象之间的交互时机、交互结果都具有了不确定性，带来了很大的安全隐患，并且多线程还会存在死锁、轮询等额外的线程不安全问题，而由于结果的不可复现性，对bug的定位和修复也变得格外困难，这都对我们编写多线程程序提出了更高的要求。因此，我们需要结合实际场景对线程安全问题进行分析和解决——哪些对象之间的交互存在着安全隐患？如何合理的加锁既能防止死锁，又能保证效率? 只有解决了线程安全问题，才能保证对象之间的交互"乱中有序"、符合预期。

第三单元

第三单元的主题是”JML规格“，要求我们能够理解JML语言，基于规格进行代码实现，或是编写相应的规格。虽然JML是一个十分冷门的语言，初看并不理解这单元的用处。但随着完成本单元三次作业之后，我能感受到课程组是想让我们感受到**”契约式编程“的魅力——高可靠性、高复用性、便于测试。另外本单元也让我明白契约仅仅是对程序的功能做出了限制，在不违背契约的前提下，还需要重点关注如何高效的实现契约，在本单元中我学习并采用了并查集、堆优化的dijkstra算法、变量维护等优化方法，学习到了很多巧妙的算法**知识。