设计模式之七大原则

一、单一职责原则[Single Responsibility Principle]---一个类只负责一项职责

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 

问题由来：类C负责两个不同的职责：职责1和职责2。当职责1的需求发生改变而需要修改类C时，可能会导致职责2的功能发生故障。

解决方案：根据单一职责原则，分别建立两个类C1和C2，实现职责P1和职责P2的功能。再有需求改变时，修改类C1不会导致职责P2发生故障；修改类C2不会导致职责P1发生故障。

所以：不能为减少代码量而把牛头和马嘴塞在一个类中

二、里氏替换原则[Liskov Substitution Principle]---继承与派生的规则

定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。通俗的说，即子类可以扩展父类的功能，但不能改变父类原有的功能。
定义2：所有引用基类的地方必须能透明地使用其子类的对象。

问题由来：有一功能P1，由类C完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类C的子类C1来完成，则子类C1在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

解决方案：1）子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法；2）子类中可以增加自己特有的方法；3）当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松；4）当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更加严格。

所以：尽量不要重写父类已经实现了的方法，可以用接口等其他方法实现

三、依赖倒置原则[Dependence Inversion Principle]---针对接口编程，不要针对实现编程

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。即针对接口编程，不要针对实现编程。通俗来说，依赖倒置原则的中心思想就是面向接口编程。

问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

所以：多用抽象的接口来描述相同的动作，降低耦合度

四、接口隔离原则[Interface Segregation Principle]---建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少

定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。

但是：接口隔离原则一定要适度，接口设计的过大过小都不好

五、迪米特法则[Law Of Demeter]---低耦合，高内聚

定义：一个对象应该对其他对象保持最少的了解。也就是说，一个类对自己依赖的类知道的越少越好。

问题由来：类与类之间的关系越密切，耦合度就越大，当一个类发生改变时对另一个类的影响也越大。

解决方案：对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。

所以：一个对象应该对其他对象保持最少的了解

六、开闭原则[Open Close Principle]---一个软件实体如类、模块和函数应该对扩展开放，对修改关闭

定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

七、组合/聚合复用原则[Composition/Aggregation Reuse Principle(CARP)]：尽量使用组合和聚合少使用继承的关系来达到复用的原则

定义：又称合成复用原则。在新的对象中使用已有的对象，使之成为新对象的一部分，新对象通过委派调用已有对象的方法达到利用其已有功能的目的。也就是说，尽量使用类的合成利用，尽量不要使用继承。

解决办法：组合或聚合关系可以将已有的对象（也可称为成员对象）纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现细节对于新对象不可见，所以这种复用又称为“黑箱”复用，相对继承关系而言，其耦合度相对较低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作；合成复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。

总之：如果两个类之间是“Has-A”的关系应使用组合或聚合，如果是“Is-A”关系可使用继承。在实现复用时应该多用关联，少用继承

文章http://www.uml.org.cn/sjms/201211023.asp中举的粟子特别好，有有助于更好的理解！！！