设计类——《软件工程:实践者的研究方法》第八版

        当设计模型发生演化时，必须定义一组设计类，它们可以：（1）通过提供设计细节对分析类进行求精，而这些设计细节将促成类的实现；（2）实现支持业务解决方案的软件基础设施。  以下给出了五种不同类型的设计类[Amb01]，每一种都表示了设计体系结构的一个不同层次:（1）用户接口类，定义人机交互（Human-Computer InteractiHCI）所必需的所有抽象，并且经常在隐喻的环境中实施 HCI；（2）业务域类，识别实现些业务域元素所必需的属性和服务（方法)，通过一个或更多的分析类进行定义；（3）过程类，实现完整的管理业务域类所必需的低层业务抽象；（4）持久类，用于表示将在软件执行之外持续存在的数据存储（例如，数据库);（5）系统类，实现软件管理和控制功能，使得系统能够运行，并在其计算环境内与外界通信。

        随着体系结构的形成，每个分析类转化为设计表示，抽象级就降低了。也就是说，分析类使用业务域的专门用语描述数据对象（以及数据对象所用的相关服务)。设计类更多地表现技术细节，用于指导实现。

         Arlow 和 Neustadt[Arl02]给出建议：应当对每个设计类进行评审，以确保设计类是“组织良好的”(well-formed)。他们为组织良好的设计类定义了四个特征。

        完整性与充分性。设计类应该完整地封装所有可以合理预见的（根据对类名的理解）存在于类中的属性和方法。例如，为视频编辑软件定义的Scene 类，只有包含与创建视频场景相关的所有合理的属性和方法时，它才是完整的。充分性确保设计类只包含那些“对实现该类的目的是足够”的方法，不多也不少。

        原始性。和一个设计类相关的方法应该关注于实现类的某一个服务。一旦服务已经被某个方法实现，类就不应该再提供完成同一事情的另外一种方法。例如，视频编辑软件的VideoClip 类，可能用属性 start-point 和 end-point 指定剪辑的起点和终点（注意，加载到系统的原始视频可能比要用的部分长)。方法 setStartPoint()和 setEndPoint()为剪辑提供了设置起点和终点的唯一手段。

       高内聚性。一个内聚的设计类具有小的、集中的职责集合，并且专注于使用属性和方法来实现那些职责。例如，视频编辑软件的 VideoClip 类可能包含一组用于编辑视频剪辑的方法。只要每个方法只关注于和视频剪辑相关的属性，内聚性就得以维持。

        低耦合性。在设计模型内，设计类之间相互协作是必然的。但是，协作应该保持在一个可以接受的最小范围内。如果设计模型高度耦合（每一个设计类都和其他所有的设计类有协作关系)，那么系统就难以实现、测试，并且维护也很费力。通常，一个子系统内的设计类对其他子系统中的类应仅有有限的了解。该限制被称作 Demeter 定律[Lie03]，该定律建议一个方法应该只向周边类中的方法发送消息。