【小话设计模式】面向对象设计原则

1.单一职责原则

    单一职责原则的核心思想就是：系统中的每一个对象都应该只有一个单独的职责，而所有对象所关注的就是自身职责的完成。英文缩写SRP  Single Responsibility Principle

    单一职责原则——》“高内聚，低耦合”，每个类应该只有一个职责，此外只能提供一种功能，而引起类变化的原因应该只有一个。在设计模式中，所有的设计模式都遵循这一原则。

    优点：

         可以降低类的复杂度；

         提高类的可读性，提高系统的可维护性；

         变更引起的风险降低。

2.里氏替换原则

    里氏替换原则的核心思想就是：在任何父类出现的地方都可以用它的子类替代。英文缩写：LSP   Liskov Substitution Principle

    里氏替换原则——》同一个继承体系中的对象应该有共同的行为特征 。

    在里氏替换原则中，所有引用基类的地方必须能够透明地使用其子类对象 。也就是，只要父类出现的地方，子类就能够出现，而且替换为子类不会产生任何错误或异常。反过来，子类出现的地方，替换为父类就可能出现问题。

    有4层含义：

          （1）子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

          （2）子类可以有自己的特性 。也就是说在类的子类上，可以定义其他的方法或属性。

          （3）覆盖或者实现父类的方法时输入参数可以被放大，反之则不行

          （4）当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

子类可以扩展父类的功能，但不能改变父类原有的功能。

3.依赖注入原则

    依赖注入原则的核心思想就是：要依赖于抽象，不要依赖于具体实现。它的英文缩写DIP  Dependence Inversion Principle(依赖反转原则）。

    依赖注入原则——》在应用程序中，所有的类如果使用或依赖于其他的类，则都应该依赖于这些其他的类的抽象类，而不是这些其他类的具体实现类。抽象层次应该不依赖于具体的实现细节，这样才能保证系统的可复用性和可维护性。为了实现这一原则，就要求开发人员在编程时针对接口编程，而不针对实现编程。

    依赖注入原则有如下三点说明：

        1.高层模块不应该依赖底层模块，两者都应该依赖于抽象（抽象类或接口）

        2.抽象（抽象类或接口）不应该依赖于细节（具体实现类）。

        3.细节（具体实现类）应该依赖抽象。

    依赖注入原则的本质是通过抽象（抽象类或接口）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。这个原则是6个原则中最难实现的了，若果没有实现这个原则，也就意味着开闭原则（对扩展开放，对修改关闭）也无法实现。

    依赖注入原则用如下三种方式实现。

    （1）通过构造函数传递依赖对象

             例如在构造函数中的需要传递的参数是抽象类或接口的方式实现。

    （2）通过setter方法传递依赖对象。

             即在我们设置的setXXX方法中的参数为抽象类或接口，来实现传递依赖对象

      (3)接口声明实现依赖对象

4.接口分离原则

    接口分离原则核心思想就是：不应该强迫客户程序依赖它们不需要使用的方法。

    英文缩写ISP，Interface Segregation Principle。

    接口分离原则——》一个接口不需要提供太多的行为，一个接口应该只提供一种对外的功能，不应该把所有的操作都封装到一个接口中。

接口分两种：

（1）对象接口

        Java中声明的一个类，通过new关键字产生的一个实例，它是对一个类型的事务的描述，这也是一种接口。

（2）类接口

      这种接口是通过关键字interface定义的接口。

      接口分离原则要求的是在一个模块中应该只依赖它需要的接口，以保证接口的小纯洁。而且需要保证接口应该尽量小，即设计接口的时候让接口尽量细化，不要定义太臃肿的接口。

     单一职责原则要求的是类和接口职责单一，注重的是职责，是业务逻辑上的划分。而接口分离原则要求的是接口的方法尽量少，针对一个模块尽量有用。

    接口分离原则的规范：

    （1）接口尽量小：主要是为了保证一个接口只服务于一个子模块或者业务逻辑。

    （2）接口高内聚：接口高内聚是对内高度依赖，对外尽可能隔离。即一个接口内部声明的方法相互之间都与某一个子模块相关，且是这个子模块必需的。

    （3）接口设计是有限度的：如果完全遵循接口分离原则的话，会出现一个问题，即接口的设计力度越来越小，这样就造成了接口数据剧增，系统复杂度一下子增加了，而这不是真实项目所需要的，所以在使用这个原则的时候，还要在特定的项目中，根据经验或者尝试去判断，但没有一个固定的标准。

5.迪米特原则

    迪米特原则LOD  Law of Demeter.

    迪米特原则的核心思想就是：一个对象应当对其他对象尽可能少地了解。意思就是降低各个对象之间的耦合，提高系统的可维护性。迪米特法则又叫最少知道原则。在模块之 间，应该只通过接口通信，而不理会模块的内部工作原理，它可以使各个模块耦合程度降到最低，促进软件的复用。

    迪米特原则的核心观念就是类间解耦，弱耦合。只有弱耦合了以后，类的复用性才可以提高。

在应用迪米特法则时的注意事项如下：

    1.在类划分上，应该创建有弱耦合的类。

    2.在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

    3.在类的设计上，只要有可能，一个类应当设计成不变的类。

    4.在对其他类的引用上，一个对对象对其他对象的引用应当降到最低。

    5.尽量降低类的访问权限。

    6.谨慎使用序列化功能。

    7.不要暴露类成员，而应该提供相应的访问器（属性）

6.开闭原则

    开闭原则缩写OCP  Open for Extension，Closed for Modification

    开闭原则的核心思想是：一个对象对扩展开放，对修改关闭。

    开闭原则的意思就是：对类的改动是通过增加代码进行的，而不是改动现有的代码，也就是说，软件开发人员一旦写出了可以运行的代码，就不应该去改变它，而是要保证它能一直运行下去，如何才能做到呢？需要借助于抽象和多态，即把可能变化的内容抽象出来，从而使抽象的部分是相对稳定的，而具体的实现层则是可以改变和扩展的。

根据开闭原则，改变软件时，应通过扩展的方式来实现软件的改变，而不应靠修改原有代码来实现变化。

    开闭原则是前5种原则的一个抽象总结，前5种是开闭原则的一些具体实现。

原文：http://blog.csdn.net/yinxiangbing/article/details/35219553