BUAA OO UNIT4单元总结

[meteoriterr]

Part1 本单元所实践的正向建模与开发

所谓正向建模，是一种自顶向下的方法。本单元课程要求先进行架构设计，画出UML类图、状态图、顺序图，再进行最终的代码编写。当然最终的实现过程有没有严格自顶向下呢就不得而知了，毕竟类图只需要扔上去几个框划几条线就行了，具体指导书又整了什么新活，写代码的时候由于水平太菜遇到夺少问题就难讲了。

不过总的来说，作者还是大体上实现了先设计，再构造的思路（始终贯彻面向对象设计与构造课程题目思想）。也体会到了设计其实是一件不容易，却用处很大的工作。设计类图的时候会考虑每一个Class的作用，怎么进行分工能实现更好的“高内聚，低耦合”，以及未来可能出现哪些新的要求，怎么设计架构能够对原有架构影响最小的情况下实现新需求。

当然，有了hw13中作者画了又改改了又画的设计，在接下来的迭代过程中，作者也切身体验到了一个合格的架构有多香，hw14和hw15基本没有进行在原有代码上的修改，仅是添加就能够完成基本要求。当然作者比较菜，该架构并不是一个十分优秀的架构，在后续任务中作者曾不止一次地骂过写hw13时的自己，怎么能写出来这么一坨。当然，这样的反思也给作者积累了很多经验，最起码作者自认为下一次的架构设计会更好一些。

Part2 架构设计

太好了我竟然有现成的类图（丑的可以）！

大体思路：
Library:进行图书馆的整体调度，处理请求，并决定把请求扔给哪个部门。

图书馆部门：
BookShelf:如其名，书架。起到一个存储的作用。

QueryMachine:查询机。起到查询的作用

BorrowLibrarian:借还处，处理和图书借还有关的操作。因为预约失败时书会再回到借还处，所以和预约处做了关联。

OrderLibrarian:预约处，处理和图书预约有关的操作。

DriftCorner:漂流角，处理和图书漂流有关的操作。

操作主体：
StudentTable:存储学生信息。留出接口，可以用来判断某id的学生是否可以进行借还、预约等操作。

BookTable:存储每个学生拥有的书籍。留出接口，可以查询该学生拥有的书籍信息，比如有没有B类书？有没有某书号的C类书？有没有过期书？

MyBook:书籍主体。存储某本书的书籍信息，如借书日期，书籍状态，拥有者等。

Part3 架构设计思维的演进

第一单元

第一单元的主要思想是递归下降。其实在这一单元已经有了正向建模开发的意思，毕竟要理解递归下降，首先就要清楚要把表达式分成几类，这几类的关系怎样，从关系中体会递归下降的思想。在这一单元作者在写代码之前就会画出基本的架构思路，设计出表达式、项、因子分别要干嘛，如何封装，怎么把表达式依次分解，这何尝不是一种简陋的类图。

第二单元

多线程，我永远的噩梦，已经对电梯ptsd了。在这一单元的“规则怪谈”中，主要学习了如何实现多线程，同时，作者也感受到了“调度器”的重要性。在多线程中调度器很重要，在非多线程情形下，调度器一样能够使程序结构更加清晰、分工更加明确。

多线程，典型的一学就会，一写就废。死锁、轮询等典型错误贯彻了我三次作业的始终，做梦都在CTLE。在一个个深夜，面对一个个CTLE时，作者也对多线程情形下的资源分配、调度关系有了更深刻的认识，看起来闹鬼一样的问题，实际上确实是自己的设计失误（除了sleep大法，某些地方我确实不知道为什么要sleep(5)，但加了就对了，神奇吧）。死锁、轮询等问题是可以通过有逻辑的设计避免的，这也提醒我们遇到问题先从自己身上找原因设计阶段一定要明确调度关系、资源分配情况，多想想总不会错。

第三单元

JML，作者曾称之为形式主义的余孽逻辑严谨的约束。一开始确实对为什么要用比具体实现还多的代码去描述代码的操作表示质疑，但是在具体接触过程中，作者发现了JML相对于自然语言描述的优越性。给出具体的限制、具体的结果，有效避免了自然语言的二义性，同时有了规格的约束，具体实现变得简单，可维护性也提高了。

当然，作者在这一单元中也意识到自己是个算法废物，只能说菜就多练...

第四单元

正向建模，作者体会到了好的架构的重要性。设计架构是一个头脑风暴的过程，总是会有很多不同但都可行的架构让作者难以抉择，不过只要是一个合理的架构，就有其存在的理由和优势，都能够准确指导接下来的具体实现和拓展。作者只能说，在架构设计方面还是需要多动手实践，才能够知道自己的架构有什么问题，在拓展性上还能有什么提高，是一个不断学习和积累经验的过程。回顾半年前oopre的架构，作者觉得在这一年的学习过程中对架构设计有了很大的提高。革命尚未成功，同志仍需努力。

Part4 测试思维的演进

Level 1

手搓——朴素，但有效。主要靠自己想到的一些普通数据和特殊数据，分别测试基本正确性和细节方面的问题。手搓数据在定位到具体问题时比较有效，能够把问题提炼出来，只用几行的数据去测试该问题是否得到了有效解决。

Level 2

伟大的DPO！当然要等到DPO更新后再开始写作业啦~感谢大佬们的维护和发电，大规模的数据能够全方位、多层次、立体化发现各种出其不意的bug。

Level 3

Junit害了我！白箱+黑箱。作者在需要写Junit之前是没接触过自己生成大规模测试数据的，在Junit测试中，作者的思路就是白箱+黑箱。白箱就是对边界数据、特殊数据等进行测试，保证特殊点能够通过测试。黑箱就是random个几千次，数据轰炸，寻找有可能存在的错误。

Part5 课程收获

首先，完结撒花~~

通过一整年的oopre+oo，作者了解了面向对象的基本方法（对象呢？对象呢？？），当然啦，学习了Java语言。今天，再回顾上学期oopre的冒险者游戏，作者还能够回想到第一次接触Java时的不知所措，和最后一次作业完成后，虽然初步会了Java，但是烂的可以的架构。证明作者这一年还是有收获、有进步的。从架构设计，到多线程，作者自以为还是掌握了不少知识。当然，在最后一次研讨课的小测中，作者的理论知识显然可以说一塌糊涂，这也让作者再次思考作为程序媛的未来，只会编程可不就是等着35岁被裁掉吗..这可真是一个令人痛心而又不得不忧虑的未来，哭。

所以啦，作者深刻认识到自己的菜，也深刻认识到学无止境啊。在这一过程中能够有幸和身边的同学们学到这么多知识，能听老师醍醐灌顶，也是蛮不错的经历。然后，菜就多练！！！

最后的最后，感谢这段时间来我的付出，我熬的大夜。当然，最重要的是感谢这一路上帮助我的所有人，我的舍友、我们的三人小群、我结识的大佬，感谢助教，感谢开发DPO的佬，感谢深夜两点钟在群里为我答疑解惑的同学们，感谢每次研讨课、交流群、讨论区中佬们的分享，让我学到了很多。

感谢这些经历，让进入6系后要死了的我，在回想起来时，是怀着愉悦的心情。我们的冒险者游戏，还没结束。

感谢陪伴！再见喽！