OO第四单元——UML图总结&课程总结

OO第四单元——UML图总结&课程总结

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

本单元是实现一个图书馆借阅系统，功能复杂，部门繁多，需要先厘清图书馆具有的各个功能以及每个部门负责的部分。

在厘清关系的部分，我们可以采用画UML图的方法，通过先行设计各个类及其相互之间的关系，从而订好一个清晰的框架，将复杂、难以理解的功能用图表现出来。再根据框架往上面添砖加瓦，从而具体化为一个有完整功能的程序。

在写程序的过程中，对照着我们事先正向建模的架构，就会很快、很容易地上手，不会被复杂的文字迷惑，并且还会降低失误率。比如本次的图书馆系统，书的种类有ABC三个等级，图书馆的处理事项很多，每个功能涉及到的部门又极其弯弯绕绕。如果不事先有一个清晰的建模出来，找到类与类间的关系及信息传递，就很容易在写程序的时候产生困惑，浪费大量时间的同时，还会产生很多因先入为主产生的bug和重构现象。

本单元作业的架构设计，对比分析最终的代码设计和UML模型设计之间的追踪关系

本单元UML图如下：

类图：

状态图：

预定书时序图：

这类图有够复杂。事实上，对于图书馆的每个员工我都设置了一个单独的类，虽然这样会提升复杂度，但是我觉得类与类之间的写作更贴近真实情况，毕竟在真实情境下需要为每个部门设置单独的功能，并且处理好类与类间的复杂信息传递与协作关系，也是面向对象的一个重点。

第一次作业我使用了单例模式——唯一的图书馆包含着各种唯一的管理员。关联关系清晰，还运用了设计模式，架构很好。在这么多次作业中，这次的面向对象感觉尤为强烈：程序以需要操作的书为主体，当学生想要借还、预定书时，对应的书就作为类间的信息进行传递，通过一系列函数改变与该功能有关的类的属性，从而完美地实现各个功能。

第二次作业的背刺令人拍案叫绝。在多个图书馆联合运营下，校际借阅成为可能，本校进口外校书籍及出口书籍份额同比大幅增长。在功能正确的基础上，我优化掉了单例模式，并新增一个类负责管理图书馆间的借阅关系。不得不说，第二次作业功能实现起来逻辑更为清晰，整个图书馆管理系统可以看作一棵根树：根节点为管理图书馆的类，下一层是各图书馆节点，在下一层是各管理员节点以及该校学生。当请求出现时，书作为传递的信息，沿着这棵树的边行动到各个类节点中，停留在每个节点处时改变该书籍与该对象的状态，即可实现功能。抛开边界情况限定的模糊性谈，这次作业设计得很好，让我们能够有一个更加缜密和清晰的逻辑，对于面向对象的理解和应用大有裨益。

第三次作业新增还书超时罚款设定，无架构变动，只是让我想起自己逾期未还的三本书还在书架上放着。

而对于代码设计与UML间的追踪关系，我认为这是顺水推舟，自然实现的。从一开始我就定好了图书馆管理系统存在的”树“的关系，并且具象化地把这棵树变为类图的方式呈现出来。再依据类图确定好具体的属性和方法，最后实现程序；而Book类设置BookStage属性，即当前本书的状态。在信息传递（函数传参）时，就会改变这本书的状态，这对应着UML状态图；在每本书传递的时候，它沿着树从一个节点到另一个节点的”路径“，其实就是UML协作图。由此可见，UML图是设计架构之时、实现程序之前，将抽象的思维具化为可视的图形，让自己的代码设计能够畅通无阻，失误也减少很多。

课程总结

架构设计思维演进

第一单元解析表达式。我认为第一次结构还算清晰，尤其是Parser，Lexer分工明确，Expr，Term和Var为运算单元，配合较好。算法主要是借鉴了公众号推送的递归下降算法，将Expr分拆为若干Term，再将Term分拆为若干Var，运算后层层递归回去，使得解析表达式实现起来十分容易。但是在后期迭代的部分没有想明白就开写了，使得后续迭代复杂度越来越高。尤其是在新增求导时新建一个类，专门求导，而不是将这个功能放到每个类里，是一次功能齐全但面向对象思想很差的迭代。另外，化简表达式也使得架构十分混乱，数据存储也很复杂，面向对象的思想没有多么深入地领悟。

第二单元多线程。我在学习的时候拘泥于生产者-消费者模式的”形“。认为人员进入作为生产者，电梯作为消费者，乘客为”货物“，两个线程实现，从而使得性能很差；除此之外我对锁的把握也不是很到位，程序中用了特别多的syncronized代码块，使得代码混乱难读，在多线程的环境下还有很多bug，无论从设计还是功能都一塌糊涂。知道第三次迭代我厘清了设计思路：仍然是输入线程作为生产者，电梯线程作为消费者，而二者之间还夹杂一个调度器线程；生产者将货物送到调度器，调度器采取策略将货物分配到合适的电梯中；对于共享资源，要么使用syncronized函数避免锁的获取和释放部分过于复杂，要么使用ReentrantReadWriteLock进行锁定，并适当地wait和notify减少cpu运转。

第三单元无向图。只需按照类和函数的JML规格进行”翻译“即可，但也有部分内容需要自己设计。在读规格、实现程序的过程中，我渐渐领悟了一个好的设计所需要具备的一些条件：类与类之间相互配合，函数功能清晰，信息传递简明扼要，符合真实情况。为了性能，我也采用了动态维护的方式来减少时间复杂度，优秀的算法往往能让设计锦上添花。

第四单元UML图。写代码前构思的过程可以用UML图来具体地描述出来，从而在写代码的时候不会迷茫，节省了很多写程序和debug的宝贵时间。有了这个工具后，复杂的问题被分散成若干个简单的问题，只需要照着图实现程序，便可写出具有良好架构的可读性高的程序。面向对象的思想也被进一步强化了，在写程序的时候会不由自主地想到采取树的解决方式，类间配合也更加地紧凑，而不是一个类实现了大部分功能。

测试思维演进

第一单元的功能其实就是python中的sympy包，能够比对两个表达式化简后是否等价。所以我简单地用python写了对拍器，并且构造了很多临界易错数据，比如表达式的八次方、表达式的零次幂、若干前缀符号的处理、函数求导以及化简表达式易错点等等数据。这也使得本单元bug找到的最全，hack成功次数最多。再借助他人分享的数据生成器进行测试，锦上添花，使得正确率很高。

第二单元我仍然构造了部分多线程情况下易错的数据，比如大量人同时进入电梯、测试捎带策略是否正常运行、残疾楼梯的运行正确性等等。由于输出结果正确性难以肉眼识别，我还是决定大量采用他人分享的测评机来测试程序正确性，能够提高效率。

第三单元采用了他人分享的评测机。

第四单元采用了他人分享的评测机。

课程收获

曾经在很多夜深人静的日子里，我质疑地看着自己改了若干遍却依旧bug无限的代码；在周末，看着测评机中不断跳出的错误信息，心情复杂；在吃饭的路上思考问题所在，在讨论区和往年程序中搜寻着更好的方法。面向对象这门课曾让我无力，让我深知自己的有限；更让我认清现实，看清了我距离自己目标的差距。

毫无疑问，这门课不仅占据大量时间，更耗费精力和心血。这门课或许是一场马拉松，留给你喘息的时间很少：周二晚七点，一项新的作业发布。自那时起，我们要在周日前读懂任务内容和目标、学懂学通新的知识点、写好程序初稿、不断修改bug。这每一项无疑都是需要精心严谨地做到的，容错率很低，任何一项出差错，都会导致本次作业出现不可预知的错误！通常在其他课上，都是写java作业的好机会。从周三写到周六，从上午写到凌晨。周日交差后，又进入互测和bug修复阶段；竭尽全力地修好了bug，最大限度地弥补损失后，等待着我们的又是下一轮循环……实验课上，我们要在两节课内读懂代码，理解其中思想，填好，测试好，也不得不说这是一项极其艰巨的任务。在屡败屡战中，我们迎来了面向对象的结课。

这一次次的车轮战后，我们必然也有很大的收获。面向对象的思维进一步强化，我们写的程序可读性强，功能强大，性能优异；我们能够清晰地从一个程序的要求中提炼出关键框架和脉络，对功能进行全面细致又优雅的呈现；我们学会了越来越多的测试方法和测试策略，学会了更多工具来确保自己的程序在正确性上、在性能上不出差错；我们懂得了集思广益，从群体诞生的智慧中提取精华为自己所用。在他人嬉笑之余，我们将精力全部付诸程序的完美实现，将时间挥洒在各种面向对象的工具书上，收获到了更多知识。

”以功利为导向的价值观常常是我们忘记人生的本质是一场历程。“写好每一次作业，保证正确，不是不可能，但绝非易事。在面向对象的课程中，我曾面临种种困惑：在繁多的课程中，平均每周要实现500行的代码量。功能复杂，要保证功能的正确，更需要逐步排查。一组数据错了，或者一步步调试找到错误点，或者不可复现转而从上百行的数据中逐步截取，直到发现错误……在艰难困苦中磨平棱角，曾经的一腔热血转变为一步一个脚印踏实地前进，曾经对程序满分的执念也变为对获得知识的满足。我终于意识到，这个付出的过程是意义非凡的，总能总结出大量有益的经验，反思自己的失败和不足，从而化作前进的动力。

前进的马拉松中，我们总能看到大佬的飞奔扬起的尘土，望尘莫及。在课程群、在讨论区，好心的同学分享出他们绝妙的算法、测评机这些好用的东西，或多或少让我减轻了部分负担。这只是他们庞然冰山的一角，却也能让井底之蛙大为震撼、自愧弗如。我越来越了解自己的有限，也默默地将他们当作是榜样，是长跑过程中的标杆。期末颁奖仪式上，每一位站在领奖台上脱颖而出的同学都是勇士，是各个领域的杰出代表。那时，我不再单纯地认为自己有限，他们的成功也让我的进步有迹可循。

面向对象课程是马拉松艰险的一段，更长的路还在脚下，通向遥远的前方。”人生如逆旅，我亦是行人。“保持清醒、敬畏和进取的心，在路途收获更美好的风景。

放首歌吧，歌名《开往早晨的午夜》：

曾像夜那么黑，每个清晨

曾阻挡每个梦，每一道门

终于也可能，无限可能，自由发生~