从实例分析如何提升软件可复用性和可维护性（软件构造实验的遗憾）

在大学的软件构造类似的课程中，我们了解过很多的设计模式，然而如何在一个具体实例中选择合适的设计模式是一个难题（困扰了我很久）。这次我通过实验中的一个较为复杂的例子来说明一下设计的心路历程。

问题说明

在这里，我简要提炼一下实验要求，挑选一部分侧重点来进行讨论。
本次实验要求设计一组计划项管理的ADT

• 可以对计划项进行：分配资源、启动、挂起、取消、停止等操作。
• 每个计划项需要占用一定的资源和地址。

要求能够实现下列5种不同的计划项：航班、高铁、进程、课程、活动。
可以看出对于不同的计划项，他们在资源数量、地址数量，以及资源地址的可修改性等各个层面都不相同。实验里总结了如下的图示总结：

设计分析

我们通过观察可知，在同一纬度内，这5个计划项的特征都有所差异，但又不是完全不同。下面我们对比分析几种不同的方案：

一、直接实现5种不同的子类型，每个维度的不同特征在子类型中体现。

这样做的坏处在于，某些维度下有些计划项的特征完全相同（如进程、课程、活动都占用一个具体的位置），这样做会造成大量的代码重复，而且后期维护会极为麻烦（改动一处代码需要寻找每一个重复的部分）

二、将所有的不同操作都放在顶层的接口上

这样做的坏处有2：

• 对于某些维度，参数类型的差异难以整合：
  例如对于位置的这个维度，由于位置的数量可能是1个，还可能是多个（大概率需要List实现）。这就会导致关于位置的方法的参数和返回值拥有着不同的类型，很难进行整合。
• 会出现很多无用方法：
  例如对于阻塞的维度，航班是不支持这个操作的，那么航班的子类型在override阻塞相关的方法时，就只能抛出异常或什么都不操作。这样的代码不利于别人学习使用，十分丑陋。

三、利用继承树实现不同维度特征的组合

这种做法是分别考虑每一种不同的维度来构造继承树，逐层组合出我们想要的ADT，但是这种方法面临着严重的组合爆炸。
举个例子：

class CommonPlanningEntry
//第一层：考虑地址维度（单地址、多地址）
class MultipleLocationEntry extends CommonPlanningEntry//多地址
class SingleLocationEntry