[设计原则1]GRASP 通用职责分配软件原则

        通用职责分配软件原则主要是解决那些功能职责放哪些类实现的问题，是讨论功能分配的问题，它介于分析和设计之间，是在类被识别之后，如何向类分配职责的的基本原则。当然在这个过程中也经常会产生新的类，或对已经识别的类做合并、抽象等。

        通常在进行用例分析和设计时，以及后面的实现类设计时，应用GRASP原则来确定类在协作中所承担的职责，这些职责主要包括：1. 谁拥有信息（掌握或通过计算引申得到的某些信息，以及相关的其他对象）；2. 做什么？自己做或者触发其他对象做某些事，以及控制或协调其他对象做某些事。然后根据这些信息以及相关的原则来分配职责。

        单一职责原则（SRP）：大多数人把该原则独立出来，但个人认为其应该是属于GRASP原则中很重要的一个原则。定义：一个类只能因为一个因素而改变。SRP说的其实是类设计时的职责划分和粒度问题，说到单一职责原则，很多人都会不屑一顾，因为它太简单了。但该原则确实违反最多的原则，不然也不会出现那么多的上帝类出来。

        但是也不能为了原则而原则，不要过度设计，如果两个功能确实同时满足以下三个特点，放一个类中实现也是可以的：1.足够的小；2.关联性很大；3重用也是完全一致。

        信息专家原则（Information Expert）：将职责分配给信息专家（类），因为它掌握了履行职责所必须的信息（数据）。这样分配有利于面向对象的封装性，同时减少不必要的关联，负荷高内聚，低耦合的设计原则。

        创建者原则（Creator）：如果满足以下条件之一，将创建类A实例的职责指派给类B：

                1）B包含了A；

                  2）B聚合了A；

                  3）B具有初始化A所需要的数据；

                  4) B记录了A的实例；

                 5）B紧密的使用A；

        应用Creator模式的好处：整个结构清晰易懂、有利于类或组件的重用、防止职责的分散、降低耦合性。

        如果不遵循Creator模式，把类的实例的创建职责交给无关的类，耦合就会更多，A的变化影响的模块也就更多，最终影响了系统的可维护性和扩展性。

        通常使用工厂模式、抽象工厂模式来完成创建，给予工厂创建A的必要数据，然后通过工厂统一创建对象，但调用工厂来创建对象的地方，也要尽量符合Creator原则。

        控制者原则（Controller）：将处理系统事件的职责分配可如下类：1）代表整个系统、设备、子系统的类；2）代表整个企业或组织的类；3）代表一个用例场景、一次会话的协调的类；

        一般可以把类分为三类，接口类、控制类、功能实体类。接口类负责与外部交互的接口转换等功能；控制类完成一个软件系统的各种业务流程；功能类完成比较具体的功能。

        Controller模式相当于著名的MVC设计模式的C（Controller）部分，通常一个功能类相对稳定，变动的可能性相对较小，但是控制类通常随着业务流程的扩展，变化较大，会越来越复杂。将这部分独立出来，能够把变化的修改范围控制在最小范围（控制器）之内，然后通过多态等手段派生出各种流程控制类出来，此时哪些功能放到控制类中就要通过控制者原则来权衡。

        多态原则（Polymorphism）：当相当选择或行为随着类型变化而变化时，将其行为的职责利用多态操作，分别指派给行为发生变化的类型。

         在未使用多态之前，这类代码通常使用if…else…或者switch case来实现，但随着类型的增加，功能越来越复杂，导致整个代码异常难以理解，更难以改动。此时通过多态来隔离这些差异，是各种分支处理独立出来，互不影响。

        多态性是面向对象的重要概念之一，它为高可扩展性程序设计提供了技术基础。所谓多态性，简单地说，就是具有同一接口的不同对象对相同的消息具有不同的行为。或者说同一消息作用于不同的对象，而产生不同的结果。         纯虚构原则（Pure Fabrication）：将一组高内聚的职责指派给一个虚构类，它不代表问题域中的任何概念，仅仅用来提供支持高内聚、低耦合与重用的行为。

        在保证高内聚，低耦合的条件下，某些职责难以分配给与现实世界相对应的问题域里的类，此时可以虚构一些与现实世界问题域之外的类出来专门处理类似功能。

        例如将数据库操作的方法从数据库实体类中剥离出来，形成专门的数据访问类，通过对类的分解来实现类的重用，新增加的数据访问类对应于数据持久化存储，它不是问题域中的概念，而是软件开发者为了处理方便而产生的虚构概念。在很多设计模式中都体现了纯虚构模式，例如适配器模式、策略模式等等。

        中介原则（Indirection）：将职责指派给一个中间对象，用来在其他构件或服务之间居中协调，以避免他们之间的直接耦合。

        要避免对象之间的直接耦合，最常用的做法是在对象之间引入一个中间对象或中介对象，通过中介对象来间接相连。比如发布订阅模式、观察者模式、适配器模式等都是该原则的体现。

        不要和陌生人说话原则：分配职责给一个客户端的直接对象以使其与一个间接对象进行协作，这样客户端无需知道这个间接对象。 其也是最少知识原则。

          受保护变化原则（Protected Variations）：找出预计有变化或不稳定的元素，为其创建稳定的“接口”而分配职责，从而保护他们不对其他元素造成不期望的影响。它使系统能够适应和隔离变化，它与面向对象设计原则中的开闭原则相对应。开闭原则后面专门讨论。