面向对象的七大设计原则

参考：http://www.tuicool.com/articles/E732Ub

单一职责原则：

问题：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
解决方案：分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。 
里氏替换原则：

保证子类能替换它的父类，即子类能够完成父类能做的事。要做到这样，就要尽量不要重载父类的方法，也尽量不要重写父类的方法，要添加新功能的话，直接新添一个方法。

迪米特法原则：

一个对象应该对其他对象保持最少的了解，从而达到降低耦合的效果。

  这里的其他对象指那些不是这个对象朋友（成员变量，方法参数，方法返回值对应的类）的对象。也就是说尽量保证某个类只与这个类的朋友进行交流。注意：局部变量不算这个类的朋友（也就是说声明一个局部变量，不能直接把这个局部变量当作这个类的朋友，但是声明一个成员变量，参数这些我们就可以直接把他们对应的类当作这个类的朋友），但是这个类必须要和局部变量交流，这么说这时我们只能将一个朋友类声明为一个局部变量。

   对于上面的朋友，我换个通俗点解释：狗这个类，给钱给狗的就是狗的朋友（声明为成员变量的，参数，返回值），由于猫这个类给钱给狗，所以猫就是狗的朋友。但是向狗借钱的不能直接算狗的朋友（声明为局部变量），而狗从来不借钱给陌生人（迪米特法原则要求），所以我们要向狗借钱我们就要是一个猫。（只能将一个朋友类声明为局部变量）

   android的activity和fragment通信是这个原则的一个例子。

依赖倒置原则：

定义： 高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。中心思想是 面向接口编程 
问题由来： 类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。 
解决方法 ：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

在实际编程中，我们一般需要做到如下3点： 

1. 低层模块尽量都要有抽象类或接口，或者两者都有。 

2. 变量的声明类型尽量是抽象类或接口。 

3. 使用继承时遵循里氏替换原则。 

依赖倒置原则就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。

接口隔离原则：

一个类对另一个类的依赖应该建立在最小的接口上。



上图中类A中通过接口I依赖于类B，类C通过接口I依赖于类D；但是类A只需要用到接口方法1，2，3；类B只需要用到接口方法1，4，5；虽然他们都存在着用不到的方法（也就是图中红色字体标记的方法），但由于实现了接口I，所以也必须要实现这些用不到的方法。

然后通过接口隔离原则进行修改：



上面的例子给我们的经验是：由于接口过于臃肿，当我们需要用到接口中的某几个方法时，我们需要构建实现类去实现接口中所有的方法，这样的设计并不完美，所以接口隔离原则起到作用。

合成/聚合原则：

尽量使用合成/聚合，尽量不要使用类继承。

为什么？

1. 对象的继承关系在编译时就定义好了，所以无法在运行时改变从父类继承的子类的实现

2.  子类的实现和它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化

3. 当你复用子类的时候，如果继承下来的实现不适合解决新的问题，则父类必须重写或者被其它更适合的类所替换， 这种依赖关系限制了灵活性，并最终限制了复用性。

开闭原则：

开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。

开闭原则具有理想主义的色彩，说的很抽象，它是面向对象设计的终极目标。其他几条原则，则可以看做是开闭原则的实现。我们要用抽象构建框架，用实现扩展细节。

七个原则都说完了，他们之间的关系怎样的？

程序，就要实现开放封闭这个目标（开放封闭原则）：要实现这个目标，由于继承的缺点，我们使用合成/聚合原则，用到组合，就说明存在了类之间的依赖，这时我们通过迪米特法原则和依赖倒转原则解决这些依赖造成的问题，这时我们就要使用到接口，处理接口的问题我们就要用到接口隔离原则，虽说继承有缺点，但继承不可避免，在处理继承时，我们就要使用里氏替换原则和单一职责原则。