OO第一次博客

代码分析

以第三次OO做业的代码为分析对象。

度量分析

类图

灰线为包内关联，红线为跨包关联。 详细类图。

自我评价

一些花了心思的设计

• Registry类的设计是源于我注意到我有遍历全部实现了Busyable, Commandar接口的对象的需求。故而利用工厂方法，使得全部实现了某个接口的对象在完成对象构造后会将本身注册进对应的Registry中。以后只须要访问对应的Registry就能够遍历全部实现了该接口的对象。
• AlterCenter类的设计是由于我注意到电梯自身对于指令也是有处理优先级的，这一部分逻辑没必要放在Command类中进行处理。剥离出这部分逻辑可使得Lift类在多指令源的环境下依然健壮执行，也简化了调度逻辑。
• Commandar接口与Busyable接口的设计，与Registry类的结合，将本来不得不在编码在调度中的逻辑分散到了各个Commandar,Busyable实现类中，极大地简化了指令获取的逻辑与程序运行结束的逻辑。

自我反省

• Command类同时承担了对输入的解析与电梯运行逻辑的执行，显得过于臃肿。或许引入一个Inputer来剥离对输入的解析，使得Command类变成与IO无关的类是个更好的作法。
• Outputer仅仅做为一个字符串处理的方法集合存在，实际的输出零散在各个类中，当须要更改输出方式的时候，我就把本身逼到死路了。或许使Outputer更充实一点，将输出逻辑更进一步地封装在Outputer中是个更好的作法。
• 全部的异常都是以RuntimeException形式存在，在异常处理的时候没法从异常对象中更进一步地获取信息，也没法在捕获异常的时候根据异常类型区分处理。或许派生出属于本身的异常时个更好的作法。
• 过于单薄的Building类，由于本来并不存在这个类，但我注意到CommandQuery, Floor, Lift之间须要一层更高级的类来绑定它们，使得它们能抱成团。可是在以后的版本更迭中我忽视了Building类的存在，并无将CommandQuery, Floor, Lift类的交互逻辑抽象进Building类中。
• Timable类的设计显得局部。本意是由于须要模拟时间，因此引入一个“该对象会随时间自动发生变化”的抽象接口，可是并无为其准备充分的资源。像是若是时间流逝的时候两个对象须要发生相互做用之类的状况并无考虑进去，而仅仅只是用来进行Lift类的状态更新与World类的时间流逝。

---

分析本身被找到的bug

但我公测和互测都没被找到bug……

---

代码测试策略

1.利用测试样例覆盖bug

利用编写的样例集，试图覆盖到程序的bug。

大多数时候是有效的也是惟一的手段，哪怕经过其余手段发现了可能的bug，最终也是用测试样例来确实地认定bug。

可是测试样例不可能覆盖到所有可能，一些出现条件苛刻而复杂的状况难以被覆盖到。

故而利用测试样例覆盖bug只能做为刚拿到程序时的摸索手段，或利用其它手段测试完程序后对bug的验证手段。

2.检查代码逻辑部分

检查代码的if,while等逻辑部分的处理是否正常。

大多数的bug都是出现于代码逻辑部分，故而优先检查if的判断语句、while的判断语句等逻辑语句是否正常，每每比较容易定位到代码的bug所在。

可是代码中的逻辑部分过于庞大、复杂，逻辑互相嵌套致使复杂度爆炸的状况也广泛存在，致使更多时候并不能彻底肯定逻辑部分代码的正确与否。

故而检查代码的逻辑部分这一手段仅适合用于局部逻辑的检查，不适合大规模代码的测试。

3.绘制控制流图

将代码中有大量判断分支的逻辑块绘制成控制流图，经过检查流图是否有缺支来寻找bug。

复杂的判断嵌套容易致使逻辑上的遗漏，经过绘制控制流图，有条理地分析每个节点应有的逻辑分支，有助于发现被遗漏的分支。

没法处理过于复杂的逻辑，当由于递归、嵌套循环等而致使复杂度爆炸时，难以简单地利用流图表示。

故而控制流图仅适用于字符串处理等线性逻辑的代码分析。

---

心得体会

第一次维护须要给别人看的代码（笑），之前就算是要维护代码，也只是维护一些本身用的小程序，因此不少地方都是“这么搞也不要紧，反正之后我也不会加那种功能”。可是此次面临的是未知的下次做业，以及随时可能更新的需求说明，因此每次OO做业都须要在完成本次做业的前提下尽可能留下下次做业的余地，以免逐渐把本身逼到走投无路、最后胡乱重构一气的下场。

一点对类设计的想法

我所遵循的设计流程是（通常都是边散步边在手机上作的x）：

1. 研读需求
2. 构造平凡样例，检验对需求理解的正确性
3. 构造非平凡样例，再次检验
4. 从需求中抽象出主要的几个类
5. 划定主要类的逻辑分工，同时抽象出BC,Interface等逻辑基类
6. 安排主要类的主要属性的结构、对外的主要接口
7. 脑内模拟跑样例，检查主要类设计的正确性
8. 设计辅助类，充实主要类的属性、接口，同时反省类设计的可行性
9. 脑内模拟跑样例，检查类设计的正确性

一些可能与他人不太同样的设计想法：

1. 在开始编写以前，我会尽可能在时间容许的条件下写一些样例来对设计进行测试，以确保设计的正确性。编写测试样例的过程自己也有助于对需求的解读。
2. 类的层次结构在主要类被抽象出来的时候就被肯定了。我尽可能避免在设计过程当中变动类的层次结构，它牵涉到设计的方方面面，我会尽可能最早肯定下来它。
3. 可行性的断定我会在编写前就尝试进行。大多数宏观的想法能够在设计过程当中就验证是否可行，不必放到编写时再进行。

一点对测试的想法

1. 能够边读代码边写测试样例。代码中的许多逻辑分支其实就和输入分支树的分支一一对应。
2. 自动化测试手段至关重要。由于咱们的做业时间极其有限（通常来讲周末写完，也就周一到周三的晚上时间能够debug，还不算文档撰写、其余课的做业的时间），重复劳动浪费的时间在总工做时间中占的比例至关可观。写一些自动化的测试脚本啥的能够说是一劳永逸。