lab3可复用性和可维护性（1）

  经历了快一整个学期的连环ddl，才想起来博客这件事。为了防止真正意义上的全部堆到期末，还不如从现在开始一边复习，一边把复习得来的总结内容放在这里。这样可以一举两得。

软件构造的lab3已经结束了。对于编码经验不足的自己来说，这次是真正意义上的挑战。前两次我还可以参考老师给出的部分代码，在上面添枝加叶即可，而这次实验需要我们从头开始设计ADT，完成中间的各种操作，一切都是从零开始的，也更贴近将来我们可能遇到的工作条件。
      本次实验要求从头对一系列的具体应用（5选3），开发一套可复用的ADT及其实现，充分利用这些ADT之间的相同点和差异性，从可复用性和可维护性两个方面来入手。
      实验的核心、就是计划项目的管理。需要实现PlanningEntry、Resource、Location、Timeslot、Board、PlanningEntryCollection等类。简单点来说就是每一项分支情况都对应着一个任务项，需要一个类来专门表示单个的任务项；而每一个任务项又分别有资源、位置、时间等属性，这些属性都会用到前面的类来表示；每个具体地点都会提供一个“信息板”，就和我们在火车站看到的信息表是类似的，上面显示过去/未来的计划项清单；最后用一个PlanningEntryCollection将一组计划项收集起来，构成一个整体。
      开发过程中，老师给出了6种方案，我选择了老师推荐的CRP方法，即设置多个接口，通过组合，委托来实现复用。我的思路就是只要两个计划项的某个属性出现相同之处，就为它们专门设计一个接口，并用相关的实现来表示。在应用子类内多用委托，用这些接口的实现类来完成这些共性操作。
      接下来就可以谈到我选择的任务类型了。限于能力，我选择了自己认为最简单的一种组合：航班管理、高铁车次管理和大学课表管理。各应用的特征如下表。
     
      从图上可以看出，我的选择使自己避开了对我来说非常棘手的多个无次序，不区分ID的资源（我甚至都不知道用什么数据结构来实现）并且位置的选择也是最简化的（全都可提前设定，只有教室在设定后可更改）。另外提一点，在我的实现中，如果一个属性没什么特点，比如无法被终止的项目（unblockable），就不会被实现。这不会对整个实验造成影响，而且降低了工作量。至此，实验的前提条件、名词解释等基本上是完成了。
      由于水平及其有限，未及之处请多谅解。