目录
第四单元部分
单元任务概述
在本单元中，课程要求我们实现了一个简单的图书馆模拟系统。该系统要能够支持普通的借书还书，以及对书的损坏，丢失，预约等特殊行为的处理，还有多所图书馆的联动校际借阅功能。最终在完成这个图书馆模拟系统的过程中，培养我们对程序架构的设计与抽象能力。
本单元正向建模与开发
正向建模与开发，个人理解为是遵循如下一种工作顺序：阅读自然语言需求——抽象出自然语言中事件发生的逻辑顺序和可能发生的情况，并通过形如UML的模型构建语言来进行阐释和刻画——根据已经构建好的思维链与模型，从代码上实现需求。采取正向建模与开发的方法，能够先从整体上把握需求情景的大致全貌，并针对性地进行设计。虽然在初期可能会有时间的消耗，但会避免混乱结构的出现并同时降低后续迭代的重构可能。而在本单元的图书馆模拟系统内，业务逻辑较为复杂，可能出现的情况颇多。故在完成本单元代码的实现时，需要先完成对问题的大致建模，再上手开发。
在作业的图书馆模拟系统中，借书是所有业务中最核心的任务。同时因为借书的流程牵扯到基本上所有可能的类之间的交互，所以也是所有业务中逻辑最为复杂的业务。因此，我在完成本单元的开发过程中，对借书的整个流程先进行了梳理，考虑不同条件下可能发生的情况与相应做出的动作。以Homework14的借书流程为例，我先完成了如下草图的绘制。
这份草图虽然没有像标准的UML图一样工整，但帮我理清了借书这一行为的大致流程。同时，流程中发生的相应操作也让我大致想清楚了部分类为了能够实现这些操作而应该有的属性和方法，为类的整体设计提供了便利。故我个人认为这也算是一种正向建模的过程，且确确实实地为我的开发指明了方向。
本单元架构设计
类图
由于本单元的状态图和顺序图都是为了满足评测需要而基于一定限制下完成的，因此我并没有在这里将这两张图展示出来，只留下了类图。如正向建模与开发部分所述，我首先分析了借书的过程，代码的设计架构和UML图的设计也都是基于这一分析完成的，所以两者能够呈现比较好的一致性（除了为了完成设计型输出而被迫添加的StateChange类）。
逐项说明
借书动作的发起者与原因
-
Book：最底层的操作对象之一，也是借书，还书等所有行为的操作对象。
-
Student：行为的主体之一。所有行为的起始动作都是由Student类发出，要求图书馆等服务单位完成后续动作。
借书动作的受理者与处理者
-
Library：是拥有书的主体之一，也是学生沟通的直接对象，拥有其他附属类来响应学生的请求。
-
BorrowOp：Library的附属类之一，负责处理B类书相关的事务。
-
Machine：Library的附属类之一，负责处理C类书相关的事务。
-
LogisticsDivision：Library的附属类之一，负责处理书籍维修相关的事务。
-
OrderOp：Library的附属类之一，负责处理校内预定的登记与发放。
-
Manager：Library的附属类之一，负责处理校际预定的登记与发放，以及新图书的购买工作。
-
-
Controller：是为了满足校际借阅而产生的更高维度的存在。由于需要负责图书馆间的协作，因此拥有图书馆的ArrayList。同时也是负责日期变更的主体。
解决借书无法当场借到的情况的工具类
-
Request：由于题目要求无法当场借阅的请求都要留到闭馆后统一处理，因此有了这一特殊类用来记载各图书馆
-
Reservation：校内预定的承载类，记录预订人，书目，时间等信息。
-
Transport & Delivery：完成校际运输而设置的辅助类。
总结部分
架构设计思维的演进
整体上来说，架构设计是面向对象这门课程培养的核心能力之一，也是一个从做题者成长到设计开发者的核心要素。由于实际需求往往是被不断提出的，迭代开发也就成了常态。好的架构设计不仅能让自己完成时思路清晰，也能减少可能的重构次数。在整个一学期的学习中，我的架构思维随单元如下变化：
Unit 1
刚刚踏入oo课程，整体思维仍然比较偏向面向过程的思路。在完成表达式的解析时，只能按照表达式的组成拆分出一些基本的类，基本上没有架构设计，是边写边想。这既导致我第一次作业完成时相当痛苦，很长时间坐在电脑前但不知道自己想要干什么；也使得部分类与方法承担的功能过于复杂，难以实现中的漏洞，最终导致第一第二次的作业中有Bug出现。
Unit 2
在吸取了上一单元的教训后，这一单元我下手实现代码时谨慎了许多。多线程交互是一个相当复杂的过程，也更需要合理的架构设计。我在这单元设计架构时，主要参考了往届学长的一些博客。在进行一些经验的学习之后，我确定了多线程的交互模式和电梯的调度与运行策略，在此基础上，架构的设计就能够比较的清晰：生产者，等待队列，消费者分别对应InputHandler，Waitlist，Elevator。Strategy为电梯运行提供策略，Person与PerRequest负责承担需求。相较于上一单元，各个类自己的功能就明确了很多。从设计层面上来看，是有一定提升的。
Unit 3
本单元的话，由于是遵循规格编程，所以不太需要进行架构层面的设计，故在此略过。
Unit 4
本单元的架构设计在开始部分就已经阐释过。相较于第一单元来看，架构设计能力已经有了比较大的提升。
测试思维的演进
说来惭愧，本学期我自己并没有捏过太多的数据。四个单元都依赖了各种各样的大佬，比如像第一单元时hlq大佬提供的评测机，第二单元时lyh大佬的评测机，第三单元ycz大佬的评测机，第四单元qshr大佬的评测机还有其他很多同学的数据。（没有他们的评测哥们的oo活不下来一点）所以以下阐述的测试思维也并不是我自己的测试思路。但在使用他人的评测机的过程中，我也的确学习了学习大佬们构造数据的方法和思路，也许也能算作测试思维演进的一部分。
Unit 1
在第一单元的学习中，由于作业主题是表达式的化简。因此测试思路主要是通过常量池和固定的表达形式随机生成一些表达式，然后用python中numpy,sympy等库的相关函数进行表达式的化简并与自己的输出进行比较来检验化简的正确性。
Unit 2
在第二单元的学习中，除了通过构造一些基础样例来检验正确性之外，性能的要求则呼唤压力性测试与边界测试的到来。在极端数据的测试下依然能够保持正确并维持较好的性能，是对一个程序质量最直接的评价。
Unit 3
相较于前两个单元，第三单元的随机性相对弱一些。一方面是因为指令的格式已经确定，只能改一些如同人名，关系值等的特殊量。更重要的是，如果生成的数据太过于随机，只能会触发设定内的异常而起不到太多的测试效果。要想要达到比较好的测试效果，需要按照一定逻辑编制数据。
Unit 4
本单元的情景细枝末节比较多，同时相较上一单元对数据的逻辑性要求更强，直接由某些常量池随机生成大量数据的方法已经不能再采用。不过因为我仔细分析了借书时的流程与各种可能发生的情况，只要根据这些情况来对应生成对应的数据并判断输出是否与预期之中的逻辑相符即可。
课程收获
一学期到了最后，OO课程也即将收尾。作为本学期投入最多的课程之一，面向对象课程也确实给予了我一些收获。
从知识层面来说，第一单元的递归下降的方法，第二单元多线程的理解与应用，第三单元规格指导实现的方式，第四单元UML语言与图的设计。每一单元都让我学到了很多，每一单元的知识也都很有特色。让我印象最深的莫过于第二单元的内容，多线程的复杂确实令人畏惧，但是灵活处理后对效率的提升也让人觉得他值得这份付出。
从代码能力层面来说，架构设计的思想确实在一个学期的代码实践中深深烙印在了我的脑海里。他就像是一份缜密严谨的事前计划，清晰地勾勒出我在每一步应该要做什么。有了良好的架构设计，写代码就有方向。这是我在本次博客中多次提到的，也是我的切身体会。像无头苍蝇一样乱撞，投入大把精力却没有成果，只能看着时间一分一秒流逝的感觉实在太过于痛苦，不希望再体会第二次。除此以外，虽然整体来说OO课程对算法没有太高的要求，但在完成任务尤其是第三单元的作业的过程里，我也接触到了一些之前没有接触过的算法和数据结构。比如说并查集的构建，按秩归并与路径压缩；比如说三元环与联通块的查询算法；还有针对多线程的一些算法等等。这些都为我相对较弱的算法方面算是补充了一些内容。
再宽泛一些，通过这门课程也认识了很多厉害的同学，在互帮互助的过程中相互结识，这同样是我在OO课程中的收获。没有身边同学与朋友的帮助，我很难做到现在的水平。无论是他们提出的解决问题的想法，还是更现实一点在评测方面无私的奉献，都不得不令我心怀感激与敬意，不断向身边的人学习。在心态方面，第一单元和第四单元也确实给了我足够的训练。第一次作业完成的痛苦经历到现在依旧记忆犹新。
总的来说，在很多方面，面向对象课程都给了机会来提升自己。希望这门课之后越来越好，Farewell。
119
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
