面向对象设计与构造第四单元及课程总结

本单元作业架构设计

Homework 13

本单元第一次作业只需要对类图进行解析，可以把需要实现的UmlInteraction类近似理解成UML图中的UmlModel，其结构层次与UmlModel的结构层次类似。同时，官方包中给出的基本类中只包含了id，name等基本属性，一方面缺少该类本应具备的重要属性，另一方面不足以反映出类与类之间的层次结构，所以需要自定义类（如MyClass、MyOperation等），封装基本类的同时扩展其属性。

Homework 14 & 15

后面两次作业增加了顺序图、状态图的处理。笔者在设计时将三种图划分为InteractionManager、ModelManager、StateManager三个类进行处理。根据UML的层次关系，笔者适当增加一些自定义的类，方便对数据的处理。

所实现的GeneralInteraction只需要调用对应Manager中的方法即可；对于所有的Manager类，查询方法和检查方法根据其访问元素的深度，在对应的类中具体实现并返回值。举例来说，类图中查询类操作的可见性，需要经历GeneralInteraction →ModelManager→MyClass→MyOperation,由MyOperaiton返回可见性。

四个单元中架构设计及OO方法理解的演进

Unit1：多项式函数求导

架构设计：第一次作业要求简单+刚接触OO年少无知，所以笔者用正则表达式就解决了任务要求。由于忽略了架构的可扩展性，在后面两次作业中被迫重构，采用递归下降的思想，将表达式、项、因子等对象用具体的类实现，并按照表达式→项→因子的层次分解，逐级处理，向上整合。

理解：本单元作业主要考察对面向对象概念的理解，锻炼学生在拿到任务时如何设计架构，划分对象及层次，实现各个对象间的联系。

Unit2：多线程电梯

架构设计：三次作业的要求可概括为：单电梯→多电梯→多类型电梯+换乘需求。笔者本单元的架构的可扩展性较好，所以三次都是迭代开发。架构中的线程类别可分为电梯线程和调度器线程。根据作业要求的变化，只需要在调度器线程中增加相应方法以实现对应功能即可；电梯线程的设计采用状态机模型，根据状态执行不同指令。

理解：本单元作业在于线程的使用，重点在于同步块的理解与处理，各线程调度实现高内聚、低耦合。线程调度依赖于自己架构清晰的设计，重点要实现线程安全，以及避免轮询造成的无意义的cpu占用。

Unit3：社交关系模拟系统

架构设计：本单元主要是根据规格完善架构设计，架构本身是一个社交关系图。实现过程上，先实现异常类，再根据完善核心属性类，如Person，Network，Message类，最终优化一些时间复杂度高的方法。

理解：本单元主要在于理解JML规格，根据效率需求进一步优化具体的方法。JML规格提供了一种保证实现正确性以及各方法独立开发的策略（即可以仅根据JML规格编写方法等代码，不需要考虑其关联），是面向开发者的一种语言。

Unit4：UML类图解析

理解：本单元考察对UML的理解和应用。设计架构完全可以参考UML本身的实现方式，分模块进行处理。对增加的检查和查询方法，只需要增加相应方法来实现所需查询功能即可，因此合理的架构是十分必要的。UML类图某种程度上也考察了我们划分对象、梳理对象层次的能力。

四个单元中测试理解与实践的演进

个人认为自己构造数据和debug的能力在四次作业中逐步增强。测试策略主要采用黑盒测试（与他人或标答对拍）和白盒测试。

第一单元中，自己对测试策略并没有太多概念，数据的构造策略主要是用xeger根据正则表达式生成随机的长表达式，与自己和其他同学的代码进行对拍。针对强度问题，我主要考虑的是对于空格的处理和括号的处理，在生成样例时尽可能生成括号嵌套和空格排列较复杂的表达式。

第二单元以黑盒测试为主（没有注释的线程代码令人头疼）。考虑到线程安全问题具有不可复现性，以及时间轴带来的不确定性，可以构造出一系列强测数据进行边界测试和压力测试，多次测试以考察线程安全。投放数据采用subprocess库来完成。

第三单元中，首先白盒测试，观察同学代码中时间复杂度较高的方法，针对该方法构造尽可能多的数据点以测试其性能；然后再构造极限长度的随机指令序列，尽可能覆盖用例以测试所有方法的正确性。

第四单元由于期末的各项测试，并没有实现较好的、完全覆盖的测试集。自己的debug策略主要是根据讨论区中同学们所提出的各种角度刁钻的问题，构造可能的UML图测试自己的代码。

课程收获

1. 对面向对象思想有了较为深入的理解，并通过实验课程的迭代开发不断强化理解。面向对象的思想与面向过程的编程有诸多不同。我们在拿到任务时，我们的分析思路应当向对象靠拢，即如何将划分对象、功能，如何实现对象及对象的功能，以及实现对象与对象之间的联系。好的架构和层次可以增加代码的可读性、可扩展性。
2. debug能力有了进一步的提升。我从对测试一窍不通的菜鸡，到逐渐学会了构造有强度梯度的样例，并且对于某一测试样例的错误能够快速定位，这都需要感谢互测环节的狼人们（都是血泪的代价）。
3. 心态上有了进一步的提升。我对于指导书的“谜语”和作业的难度逐渐放平心态，享受每次作业的编程过程和找出bug时的一瞬间的成就感，可能这就是痛并快乐着吧。

改进建议

1. 指导书的编写可以更加清楚一点，当然我认为指导书在大部分情况下避免了自然语言的二义性，是逻辑清楚的（这里只是想点名第四单元，我能理解临近考期助教也不容易，但讨论区有这么多人问问题不是没有道理的）
2. 互测机制容易让人划水，但其实哪怕是读读别人的代码也是有收益的。可以对互测机制的权重做一些调整。
3. 个人认为临近考期的作业安排可以作适当调整，例如省去了互测环节的同时适当延长公测的ddl。