BUAA OO 生涯总结！

[黄弘烨-22371430]

UNIT4 建模与架构设计流程

大纲的确定

本次的UNIT4作业旨在设计一种完整的图书馆管理系统，用来管理图书的各种借阅行为。

在第一次看到作业要求时，我的脑海里就完成了初步的建模，确定了最开始必然需要的若干个类：Library、BorrrowOffice、AppointmentOffice、BookShelf、User。后面四个类统一被Library类引用，而整个书籍的流动，其实就是书籍在这后面四个类中漂流的过程。

初步确定这数个类的关系后，下一步就是具体地定义这几个类的行为职责了。Library类其实就是整个系统的封装；而具体的书籍流动逻辑则要依赖于后面的四类。在编写UML形成最初的想法时，我即刻意识到后面四个类其实本质上都极其相似，都是用于存放书籍的地方，进而可以将这四个类统一抽象出一个更高层的抽象类BookContainer，这个类包含的就是书籍的数目已经对书籍的查询、移动等操作。上面的四个类都继承自它，通过这种类继承的方式，可以节省大量的代码量，也让我更好地把握了问题的逻辑关系。

而确定大纲之后，接下来的实现流程便顺风顺水，在后续的迭代中，也体现了我最初的设计的优越之处，在新增DriftCorner的时候，只需要将其直接继承BookContainer即可，无需再新增其他任何改动。

值得改进的缺漏

要说整个架构最让我觉得需要改进的地方，其实就在于对书籍的管理上。按照Unit2中我的写法，本来是应该要对官方包的类进行一层封装的，但由于第一次作业中贪图方便，直接使用了LibraryBookId来表示书籍，直接导致后面在处理书的多态时，额外编写了相当多的代码逻辑。倘若我最一开始就封装一个LibraryBook类，里面包含LibraryBookId，那么之后在图书分类、判断书籍的归属，尤其是记录大量额外信息（比如书籍的过期时间）时，就可以节省大量力气，简化复杂的逻辑。

正是因为我没有封装官方包，导致后面我倘若要记录过期时间、预定时间还有预定人的时候，必须额外新建新的多个容器分别存储各个属性，大大降低了代码的重用性和可读性。

UML模型的追踪关系

使用先UML后代码的方式，可以体会到明显的思路的转变，最初的思路是框架，确定了整个代码的走向，但是相对的，细节又可能不到位，一旦自己的预期有些不符合实际（或者性能不够），就常常出现修改参数、修改属性等等各种情况。

比较舒服的方式是，先使用UML打下最基本的草稿，比如对于我的作业来说，就是先确定Library、BorrrowOffice、AppointmentOffice、BookShelf、User这几个类，以及BorrrowOffice、AppointmentOffice、BookShelf、User对BookContainer的继承关系。也就是这整个的框架。

而在确立了框架之后，就将UML撇在一边，完成自己的代码，沉浸在coding中，完成具体的细节。

最后在回过头来补全UML，你会有不一样的体会。

总结下来就是：不管是纯粹的先UML再CODING，还是纯粹的CODING之后再UML，都是不够高效且正确的。我们需要根据自己的情况，找到最舒服最合适的平衡点。

我的思维进化——越来越“面向对象”

最初的UNIT1第一次作业，我对于类的态度是：好用，但代码量高，也就是保持了竞赛代码的思维，尽量少建多个模块，从而减少多个模块之间连接的代码量。能不新建类，就不新建类。

而这也让我在第一次作业改到第二次作业时吃了苦头：由于我的exp类和展开后的多项式类没有分开，term类和展开后的单项式类没有分开，导致我在处理两种类时，容易乱套导致各种bug，进而导致非常高难度的debug。这一切原因都是在于，我最初设想时虽然意识到了这两个事物本质不同，但是为了省代码少建了类，结果就是为了省下新建类的代码，反而付出了更多的代码量和精力，南辕北辙！

在第一单元结束后，我的OO意识就得到了进化，在之后的UNIT2当中，我就学会了新建多个类、谨慎继承以及封装官方包等多种“面向对象”操作，这也使得我第二单元的代码极其优雅精炼。

而在UNIT3和UNIT4中，通过JML和UML的学习，我领悟了团队协作的各种方式，通过代码来表达自己的架构往往比口述要直观的多；而规范各种程序的出口入口，前件后件则是避免遗漏重复与触发异常的重要途径。

经过OO的“打造”，我越来越“面向对象”了！

测试之路，从DEBUG苦手到调试高手

回想上个学期的OOpre，那时我就有调试不出bug的经历。在看这个学期最初UNIT1的DEBUG，可谓是“一个人，一支烟，一个bug调半天”，虽然我不抽烟，但是debug真的很痛苦。那时递归下降涉及大量的递归、重复调用，已经嵌套式的数据结构，想要找到某一处的错误简直难如登天。尤其是当时我并不熟悉vscode的调试工具链，也没有长时间debug大型项目的经历（以前的debug都是算法题，很easy）

随着慢慢的各种被折磨，渐渐地领悟了调试的完整工具链，也形成了一套独特的调试方式，不管是使用断点式、监控式、print式，我都能快速准确地定位问题所在了。

而测试除了debug过程的另一个重点，就是在于数据。找到产生bug的数据，也是一种艺术。从最初的过于依赖评测机以及眼瞪代码，变成自己构造数据（评测机）以及手搓特殊数据，我已经成为半步调试高手。

课程收获

感谢OO带给我思维上的转变、知识上的升华以及实战的得心应手，带着OO学到的一身本领，我相信我能走的更高更远，此一别非永别，让我们以后再见，我目前最爱的专业课——OO！