节选牛人模式6原则阐释

节选自http://blog.csdn.net/zhengzhb/article/details/7289269

迪米特法则

定义：一个对象应该对其他对象保持最少的了解。

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

解决方案：尽量降低类与类之间的耦合。

         自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么样编程才能做到低耦合呢？那正是迪米特法则要去完成的。

         迪米特法则又叫最少知道原则，最早是在1987年由美国Northeastern University的Ian Holland提出。通俗的来讲，就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。迪米特法则还有一个更简单的定义：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

接口隔离原则

定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

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

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

开闭原则

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

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

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

单一职责原则

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

问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

里氏替换原则

定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

定义2：所有引用基类的地方必须能透明地使用其子类的对象。

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

解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法

依赖倒置原则

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

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

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

         依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

         依赖倒置原则的核心思想是 面向接口编程

创建类型的模式包括

· 工厂模式 (Factory Pattern) - 根据工厂模式实现的类可以根据提供的数据生成一组类中某一个类的实例，而这一组类有一个公共的抽象父类。
· 抽象工厂模式 (Abstract Factory Pattern) - 抽象工厂模式也可以根据提供的数据生成一组类中某一个类的实例，而这一组类有一个公共的抽象父类。只不过它定义的是一个接口。
· 单例模式 (Singleton Pattern) - 根据单一模式实现的类只允许有一个是类，并且提供了一个全局指针来引用该实例。
· 原型模式 (Prototype Pattern) - 原型模式通过对类的实例进行拷贝来创建新的实例。
· 创建者模式 (Builder Pattern) - 构造者模式将一个复杂对象的构造过程和它的表现层分离开来，这样类就可以根据不同情况展现出不同的表现方式。

结构类型的模式
结构类型的模式将类和对象组合起来，以构成更加复杂的结构。它又被划分为类模式和对象模式。类模式和对象模式之间的区别在于类模式通过继承关系来提供有效的接口；
而类模式通过对象合成或将对象包含在其它对象中的方式构成更加复杂的结构。

· 适配器模式 (Adapter Pattern) - 适配器模式可以将一个类的接口和另一个类的接口匹配起来。
· 桥接模式 (Bridge Pattern) - 桥梁模式对客户端程序提供一个固定的接口，但是允许开发人员变化实际的实现类。这样开发人员就可以将接口是具体的实现类分离开来。
· 组合模式 (Composite Pattern) - 复合模式可以将多个对象进行复合，其中的每个对象可以是简单对象，也可以是复合对象。
· 代理模式 (Proxy Pattern) - 代理模式利用一个简单的对象替代一个复杂的对象，当复杂对象在需要的时候才会被加载到系统中，这样可以节约系统资源，提高系统的响应速度。在网络环境中这种模式很有用处。
· 装饰模式 (Decorator Pattern) - 通过修饰模式，开发人员可以在运行时将特定的功能绑定在对象上。
· 轻量模式 (Flyweight Pattern) - 轻量模式通过将对象中的一部分数据保存在对象外，在调用对象中的方法时再将这些数据传回对象。这样做可以减少大量比较简单的对象占用的空间。
· 门面模式 (Facade Pattern) - 正面模式将复杂的类层次结构组织起来，通过一个简单的接口来获得层次结构中的数据。

行为类型的模式
行为类型的模式主要是那些处理对象之间通讯的模式，该类型的包括以下模式

· 观察者模式 (Observer Pattern) - 观测者模式可以在发生变化时将变化通知多个类。
· 中介者模式 (Mediator Pattern) - 中介模式可以通过一个中间类来控制若干个类之间的通讯，并且这些类相互之间不需要了解对方的信息。
· 访问者模式 (Visitor Pattern) - 访问者模式通过一个访问类来访问其他类中的数据。
· 备忘录模式 (Memento Pattern) - 回忆模式可以在不破坏对象封装性的前提下保存和恢复对象的内部状态。
· 责任链模式 (Chain of Responsibility) - 职责链模式将请求传递给一组对象，只有特定的对象才会处理该请求。这样就进一步削弱类之间的联系。
· 命令模式 (Command Pattern) - 命令模式将请求传递给特定的对象，这样客户端即使在不知道服务器端如何处理请求的情况下也可以发送请求。
· 模板模式 (Template Pattern) - 模板模式提供了对算法的抽象定义。
· 策略模式 (Strategy Pattern) - 策略模式定义了一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化。
· 状态模式 (State Pattern) - 状态模式将一个类实例的变量保存在独立的内存空间中。
· 迭代模式 (Iterator Pattern) - 迭代模式在不知道数据的内部表现形式的前提下，通过标准的接口来遍历数据集合中的数据。
· 解释器模式 (Interpreter Pattern) - 定义语言的文法，并且建立一个解释器来解释该语言中的句子.