本文主要是介绍BUAA-2024年春-OO第四单元总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
正向建模与开发
在本单元中，我们需要模拟一个小型的图书管理系统，完成图书馆所支持的相关业务，并遵守一定的规章制度。与前几次不同的是，本单元中，我们需要预先将自己的设计思路用UML来实现，然后进行编程。
具体而言，在本单元中，我们分别使用UML类图、状态图和顺序图来进行正向建模。类图主要展示各个类之间的关联、依赖、组合、聚合关系等；状态图则需要通过trigger、guard等来表示不同状态之间的转化；顺序图则反应一个对象之间的消息传递和时序问题。
笔者在每单元的作业中会先进行较为粗略的建模，从而确定大致的编程思路。为了通过公测，我会在代码完成编写之后再对UML图进行补充和修改。
架构设计
下图是我完成hw15后的代码规模。
这是我本单元的UML类图。
我在本单元中一共实现了12个类，除了Main类之外，我建立了Library类、BookShelf类、AppOffice类、BrOffice类和BdCorner类来作为图书馆的主体，建立AppInfo类、ReserveInfo类、PersonInfo类和BsBookInfo类、BdcBookInfo类来作为存储信息的载体，用于保存和Book相关的信息。
对于图书馆的业务请求，我采用将请求逐级进行判断的方式，以BookShelf中的书籍为例，用户的query请求，因其不涉及对于书籍的改动，所以直接在Library中调用BookShelf的方法即可；而对于用户的borrow请求，我首先在Library中调用BookShelf中的attemptBorrow()方法，而在attemptBorrow方法中我再调用PersonInfo的canBorrow方法，实现了自顶向下的实现方法。
对于用户的信息，我在Library中建立了一个HashMap<StudentId, PersonInfo> personMap来记录所有用户的信息，在AppOffice类、BrOffice等具体部门类的构造方法中传入personMap，从而使得personMap的起始地址在各个部门中都能够访问，而不需要重复占用内存。
OO课程架构设计推进
其实在OO的每一个单元和OOpre中都用到了架构设计的思想，但是在之前的作业中没有要求使用UML来绘制架构设计图。
第一单元：我在第一单元中最开始关于架构设计完全摸不着头脑，我的设计完全是根据实验部分的代码修改而来，可能是课程组没有想在第一单元就这么考察我们的设计能力罢。第一单元中我认为最突出的是层次化设计，从expr、term到factor，层层深入。同时第一单元也警示我们好的设计架构可以避免后续扩展中不必要的麻烦甚至是重构的风险。
第二单元：在此单元中我第一次接触了多线程的思想，我认为在第二单元中锻炼的更多的是对于多线程中共享资源的认知和保护，同时也涉及了诸如生产者-消费者模型以及LOOK等电梯算法的思想。
第三单元：我认为在这个单元中架构设计没有前几个单元突出，主要是对JML进行编程实现，只有在需要考虑降低复杂度等特殊情况下才需要从总体架构出发进行优化，对于一些简单的方法似乎并不太需要对于架构有一个很好的把握，只需要选择合适的容器就可以独立编程实现。
第四单元：在本单元中我学习了UML类图、状态图和顺序图等与架构设计建模密切相关的知识。虽然本单元中实现的图书馆管理系统并没有前几个单元的作业难度那么大，但是很好地帮助我们理解正向建模给人带来的思维上的清晰。
OO课程测试思维推进
由于没有自己独立地搭建评测机，我在测试中更多的是采用手动捏造数据的方法来检测自己的程序是否实现相应的功能。但是这种方法很难覆盖较大范围的数据，而且也不易发现代码的bug，往往只能满足最基础的功能需求。
课程收获
OO是目前为止对代码量要求最大的一门课。正如荣文戈老师所说，“写一百万行代码的程序员和写一千万行代码的程序员，就是不一样”。虽然我远远没有达到那种境界，但是经过一学期的锻炼我确实感受颇多。举个例子，在这学期初，我的一个高中同学曾让我帮忙写他们学校布置的计算机大作业，内容也是实现一个图书馆管理系统，甚至比OO第四单元需要实现的要求还要少很多，但当时的我却无法帮他完成。而经过前三个单元的历练，我认为第四单元远远没有想象中那么困难。可见OO对于一个程序员的锻炼作用。
OO更像是一个全方位的锻炼，我们不仅需要在短时间内编写大量的代码，还需要考虑多线程、算法、架构设计等诸多问题。回首OO，虽然自己在有些作业中表现不佳，但是能完完整整经历OO的洗礼，真的让人成就满满。
希望课程组能够越来越好，给明年的xdx更大的考验（不是）。
这篇关于BUAA-2024年春-OO第四单元总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
