面向对象设计的一些基本原则

1. 优先使用（对象）组合，而非（类）继承。Favor Composition Over Inheritance。
   组合：是一种通过创建一个组合了其它对象的对象，从而获得新功能的复用方法。组合将功能委托给所组合的一个对象，从而获得新功能。有些时候也称之为“聚合”（aggregation）或“包容”（containment）。
   继承：是一种通过扩展一个已有对象的实现，从而获得新功能的复用方法。
   类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性，子类与父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

2. 针对接口编程，而非（接口的）实现。Program To An Interface， Not An Implementation。
   客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口
   接口是一个对象在对其它的对象进行调用时所知道的方法集合。一个对象可以有多个接口，类型是对象的一个特定的接口。不同的对象可以具有相同的类型，而且一个对象可以具有多个不同的类型。一个对象仅能通过其接口才会被其它对象所了解。
   实现继承（类继承）：一个对象的实现是根据另一个对象的实现来定义的。
   接口继承（子类型化）：描述了一个对象可在什么时候被用来替代另一个对象。
   优点：Client不必知道其使用对象的具体所属类。一个对象可以很容易地被（实现了相同接口的）的另一个对象所替换。对象间的连接不必硬绑定（hardwire）到一个具体类的对象上，因此增加了灵活性。松散藕合（loosens coupling）。增加了重用的可能性。提高了（对象）组合的机率，因为被包含对象可以是任何实现了一个指定接口的类。
  
3. 开放－封闭法则（OCP）：模块应对扩展开放，而对修改关闭。
   模块应尽量在不修改原代码的情况下进行扩展。Software Entities Should Be Open For Extension，But Closed For Modification。此原则是由"Bertrand Meyer"提出的。
   开放-封闭法则认为我们应该试图去设计出永远也不需要改变的模块。我们可以添加新代码来扩展系统的行为。我们不能对已有的代码进行修改。在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。符合OCP的模块需满足两个标准：可扩展，即“对扩展是开放的”（Open For Extension）－模块的行为可以被扩展，以需要满足新的需求。可更改，即“对更改是封闭的”（Closed for Modification）－模块的源代码是允许进行改动的。

4. Liskov替换法则（LSP）：子类应当可以替换父类并可以出现在父类能够出现的任何地方。Function That Use Referennces To Base(Super) Classes Must Be Able To Use Objects Of Derived(Sub) Classes Without Knowing It 。为了保持LSP（并与开放－封闭法则一起），所有子类必须符合使用其基类的client所期望的行为。它同样可以从Bertrand Meyer 的DBC (Design by Contract) 的概念推出。
5. 依赖原则 (the Dependency Inversion Principle DIP)：在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。
6. 接口分离原则（the Interface Segregation Principle ISP）：采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。
7. 单一职责原则（SRP）：一个类应该仅有一个引起它变化的原因。
   封装变化：使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。
 
基于职责设计对象(GRASP)：General Responsibility Assignment Software Pattern
类的职责是类的契约和义务，包括行为职责（初始化其他对象、控制和协调其他对象的活动）和认知职责（对私有封装数据的认知、对其他对象的认知、对其能够导出或计算出的对象的认知）。GRASP是关于对象设计和职责分配的一组基本原则，有以下原则：
1. 创建者：如果以下条件之一（越多越好）为真时，将创建A的职责分配给B
B包含或组成聚集A
B记录A
B直接使用A
B具有A初始化所需要的数据，并且在创建A的时候会将这些数据传递给A
基本意图是寻找在任何情况下都与被创建者有直接连接的创建者。
2. 信息专家：把职责分配给具有实现这个职责所必需信息的信息专家（分配职责从清晰买描述对象职责开始，把职责分配给具有完成此职责所需信息的对象。“知其责，行其事”）。
3. 低耦合：分配职责，使耦合性尽可能低（低耦合是制定设计决策的时候必须牢记的原则）。
4. 控制器：把职责分配给能够代表以下选择之一的对象（控制器是在UI层首先接收和协调系统操作信息的第一个对象）。
代表整个系统、跟系统、运行软件的设备或主要的子系统。这些事外观控制器的所有变体。
代表用例场景，在该场景中发生的事件通常命名为<..>Handler/Session等。这些事用例或会话控制器。
5. 高内聚：分配职责要保持较高的内聚性（高内聚：元素具有高度的相关的职责，而且没有过多的职责）。
6. 多态：当相关选择或行为随类型（类）有所不同时，使用多态操作为变化的行为分配职责。
7. 纯虚构：对认为制造的一组类分配一组高内聚的职责，该类并不代表问题域的概念—虚构的事物，用以支持高内聚、低耦合和复用。
8. 间接性：将职责分配给中介对象，使其作为其他构件或服务之间的媒体，以避免他们之间的直接耦合。
9. 防止变异：识别或预计变化或不稳定之处，分配职责用以在这些变化之处创建稳定的接口。