java 设计模式的原则

一、单一职责原则(Single Responsibility Principle, SRP)

     定义：There should never be more than one reason for a class to change

     一个类应该只有一个职责且仅有一个引起变化的原因，对象不应该承担太多的职责，这样能够保证对象的高内聚和细粒度。对象的高内聚和细粒度有利于对象的重用。一个庞大的对象承担了太多的职责，当客户端需要该对象的某一个职责时，却不得不将所有的职责都包含进来，从而造成冗余代码。

    优点：

1. 降低类的复杂性。
2. 提高类的可读性。
3. 提高代码的可维护性和复用性。
4. 降低因变更而引起的风险。

二、里氏替换原则(Liskov Substitution Principle, LSP)

    定义：如果对一个类型为S的对象o1，都有类型为T的对象o2，使得以S定义的所有程序P中所有对象o1都替换成o2时，程序P的行为没有发生变化，那么类型T是类型S的子类型。

继承的优点：

1. 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性。
2. 提高代码的可重用性。
3. 提高代码的可扩展性。
4. 提高项目的开放性。

继承的缺点：

1. 继承是入侵式的。只要继承，就必须拥有父类的所有属性和方法。
2. 降低代码的灵活性。子类必须拥有父类的属性和方法，子类受到限制。
3. 增强耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种修改可能造成大片的代码需要重构。

里氏替换原则为良好的继承定义了一个规范

• 子类必须完全实现父类的方法。
• 子类可以有自己的个性。
• 子类覆盖或实现父类的方法时输入参数可以被放大。
• 子类覆盖或实现父类的方法时输出结果可以被缩小。

三、依赖倒置原则(Dependence Inversion Principle, DIP)

     定义：高层模块不应该依赖底层模块，两者都依赖其抽象。抽象不依赖细节。细节应该依赖于抽象。

该原则在Java语言中的表现是：

• 模块间的依赖通过抽象产生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生。
• 接口或抽象类不依赖于实现类，实现类依赖于接口或抽象类。

依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。依赖倒置原则是JavaBean、EJB和COM等组件设计模型背后的基本原则。

在项目中使用这个原则需要遵循以下几个规则：

• 每个类应该都具有接口或抽象类，或者同时具备抽象类和接口。这是基本要求，接口和抽象类都是抽象的，有了抽象才可能有依赖倒置。
• 变量的表面类型尽量是接口或者抽象类。
• 任何类都不应该从具体类派生。
• 尽量不要重写基类的方法。如果基类是一个抽象类，而且其方法已经实现了，子类尽量不要重写。类之间依赖的是抽象，重写了抽象方法，对依赖的稳定性会产生一定的影响。
• 结合里氏替换原则使用。里氏替换原则指出父类出现的地方子类就可以出现。可以得出：接口负责定义抽象方法，并且声明与其他对象的依赖关系；抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。

四、接口隔离原则(Interface Segregation Principle, ISP)

     定义： 1. 客户端不应该依赖它不需要的接口。

                 2. 类间的依赖关系应该建立在最小的接口上。

具体含义：

• 一个类对另外一个类的依赖性应当是建立在最小的接口上。
• 一个接口代表一个角色，不应该将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。因此使用多个专门的接口比使用单一的总接口要好。
• 不应该强迫客户依赖于他们不用的方法。接口属于客户，不属于它所在的类层次结构。即不要强迫客户使用他们不用的方法，否则这些客户就会面临由于这些不使用的方法的改变所带来的问题。 

五、迪米特法则(Law of Demeter, LoD)

       定义：

• 只与你直接的朋友们通信。
• 不要跟陌生人说话。
• 每一个软件单位对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密切相关的软件单位。   

六、开闭原则(Open-Closed Principle, OCP)

      定义：一个软件实体应当对扩展开放，对修改关闭。

在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。即应当可以在不必修改源代码的情况下改变这个模块的行为。

• 提高复用性。
• 提高可维护性。
• 提高灵活性。
• 易于测试。