Java六大设计原则

时间  2019-11-20
标签 java 六大 设计 原则 栏目 Java 繁體版
原文   原文链接
类的设计原则   


  1. 依赖倒置原则－Dependency Inversion Principle (DIP) 
  2. 里氏替换原则－Liskov Substitution Principle (LSP) 
  3. 接口分隔原则－Interface Segregation Principle (ISP) 
  4. 单一职责原则－Single Responsibility Principle (SRP) 
  5. 开闭原则－The Open-Closed Principle (OCP)

一. Dependency Inversion Principle (DIP) - 依赖倒置原则 java

      依赖：在程序设计中，若是一个模块a使用或调用了另外一个模块b，咱们称模块a依赖模块b。 设计模式

高层模块与低层模块：每每在一个应用程序中，咱们有一些低层次的类，这些类实现了一些基本的或初级的操做，咱们称之为低层模块；另外有一些高层次的类，这些类封装了某些复杂的逻辑，而且依赖于低层次的类，这些类咱们称之为高层模块。 this

依赖倒置原则的2个重要方针： spa

A. 高层模块不该该依赖于低层模块，两者都应该依赖于抽象
B. 抽象不该该依赖于细节，细节应该依赖于抽象 设计

为何叫作依赖倒置（Dependency Inversion）呢？ code

面向对象程序设计相对于面向过程（结构化）程序设计而言，依赖关系被倒置了。由于传统的结构化程序设计中，高层模块老是依赖于低层模块。 orm
问题的提出：


Robert C. Martin在原文中给出了“Bad Design”的定义： 对象

1. 系统很难改变，由于每一个改变都会影响其余不少部分。
2. 当你对某地方作一修改，系统的看似无关的其余部分都不工做了。
3. 系统很难被另一个应用重用，由于你很难将要重用的部分从系统中分离开来。

致使“Bad Design”的很大缘由是“高层模块”过度依赖“低层模块”。一个良好的设计应该是系统的每一部分都是可替换的。若是“高层模块”过度依赖“低层模块”，一方面一旦“低层模块”须要替换或者修改，“高层模块”将受到影响；另外一方面，高层模块很难能够重用。

好比，一个Copy模块，须要把来自Keyboard的输入复制到Print，即便对Keyboard和Print的封装已经作得很是好，但若是Copy模块里直接使用Keyboard与Print，Copy任很难被其余应用环境（好比须要输出到磁盘时）重用。 继承

问题的解决： 接口

为了解决上述问题，Robert C. Martin提出了OO设计的Dependency Inversion Principle (DIP) 原则。

    DIP给出了一个解决方案：在高层模块与低层模块之间，引入一个抽象接口层。
High Level Classes（高层模块） --> Abstraction Layer（抽象接口层） --> Low Level Classes（低层模块）
抽象接口是对低层模块的抽象，低层模块继承或实现该抽象接口。
这样，高层模块不直接依赖低层模块，高层模块与低层模块都依赖抽象接口层。
固然，抽象也不依赖低层模块的实现细节，低层模块依赖（继承或实现）抽象定义。

Robert C. Martin给出的DIP方案的类的结构图：

PolicyLayer-->MechanismInterface(abstract)--MechanismLayer-->UtilityInterface(abstract)--UtilityLayer
类与类之间都经过Abstract Layer来组合关系。

二. Liskov Substitution Principle (LSP) - 里氏替换原则

全部引用基类的地方必须能透明地使用其子类的对象。也就是说，只有知足如下2个条件的OO设计才可被认为是知足了LSP原则：

A  不该该在代码中出现if/else之类对子类类型进行判断的条件。如下代码就违反LSP定义。
 


if (obj typeof Class1) {
     do something
} else if (obj typeof Class2) {
     do something else
}
B  子类应当能够替换父类并出如今父类可以出现的任何地方，或者说若是咱们把代码中使用基类的地方用它的子类所代替，代码还能正常工做。

里氏替换原则LSP是使代码符合开闭原则的一个重要保证。同时LSP体现了：
1） 类的继承原则：若是一个继承类的对象可能会在基类出现地方出现运行错误，则该子类不该该从该基类继承，或者说，应该从新设计它们之间的关系。
2）动做正确性保证：从另外一个侧面上保证了符合LSP设计原则的类的扩展不会给已有的系统引入新的错误。

类的继承原则：
Robert C. Martin举了Rectangle和Square的例子。这里沿用这个例子，但用Java语言对其加以重写，并忽略了某些细节只列出下面的精要部分来讲明 里氏替换原则 对类的继承上的约束。
class Rectangle {
    double width;
    double height;

    public double getHeight() {
        return height;
    }

    public void setHeight(double height) {
        this.height = height;
    }

    public double getWidth() {
        return width;
    }

    public void setWidth(double width) {
        this.width = width;
    }
}
class Square extends Rectangle {
    public void setHeight(double height) {
        super.setHeight(height);
        super.setWidth(height);
    }

    public void setWidth(double width) {
        super.setHeight(width);
        super.setWidth(width);
    }
}
这里Rectangle是基类，Square从Rectangle继承。这种继承关系有什么问题吗？

假如已有的系统中存在如下既有的业务逻辑代码：

 
void g(Rectangle r) {
     r.setWidth(5);
     r.setHeight(4);
     if (r.getWidth() * r.getHeight() != 20) {
         throw new RuntimeException();
     }
}
则对应于扩展类Square，在调用既有业务逻辑时： 

Rectangle square = new Square();
g(square);

时会抛出一个RuntimeException异常。这显然违反了LSP原则。

动做正确性保证：
由于LSP对子类的约束，因此为已存在的类作扩展构造一个新的子类时，根据LSP的定义，不会给已有的系统引入新的错误。

Design by Contract

         根据Bertrand Meyer提出的Design by Contract（DBC：基于合同的设计）概念的描述，对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等，只有前提条件获得知足时，这个方法才能被调用；同时后续条件用来讲明这个方法完成时的状态，若是一个方法的执行会致使这个方法的后续条件不成立，那么此方法也不该该正常返回。
         如今把前提条件以及后续条件应用到继承子类中，子类方法应该知足：
１）前提条件不强于基类．
２）后续条件不弱于基类．
        换句话说，经过基类的接口调用一个对象时，用户只知道基类前提条件以及后续条件。所以继承类不得要求用户提供比基类方法要求的更强的前提条件，亦即，继承类方法必须接受任何基类方法能接受的任何条件（参数）。一样，继承类必须顺从基类的全部后续条件，亦即，继承类方法的行为和输出不得违反由基类创建起来的任何约束，不能让用户对继承类方法的输出感到困惑。这样，咱们就有了基于合同的LSP，基于合同的LSP是LSP的一种强化。

       在不少状况下，在设计初期咱们类之间的关系不是很明确，LSP则给了咱们一个判断和设计类之间关系的基准：需不须要继承，以及怎样设计继承关系。



三. Interface Segregation Principle (ISP) - 接口分隔原则

      不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。它包含了2层意思：
1）接口的设计原则：接口的设计应该遵循最小接口原则，不要把用户不使用的方法塞进同一个接口里。
   若是一个接口的方法没有被使用到，则说明该接口过胖，应该将其分割成几个功能专注的接口。
2）接口的依赖（继承）原则：若是一个接口a依赖（继承）另外一个接口b，则接口a至关于继承了接口b的方法，那么继承了接口b后的接口a也应该遵循上述原则：不该该包含用户不使用的方法。   反之，则说明接口a被b给污染了，应该从新设计它们的关系。

      若是用户被迫依赖他们不使用的接口，当接口发生改变时，他们也不得不跟着改变。换而言之，一个用户依赖了未使用但被其余用户使用的接口，当其余用户修改该接口时，依赖该接口的全部用户都将受到影响。这显然违反了开闭原则，也不是咱们所指望的。

下面咱们举例说明怎么设计接口或类之间的关系，使其不违反ISP原则。
假若有一个Door，有lock，unlock功能，另外，能够在Door上安装一个Alarm而使其具备报警功能。用户能够选择通常的Door，也能够选择具备报警功能的Door。

有如下几种设计方法：

ISP原则的违反例：

方法一：
在Door接口里定义全部的方法。图：

但这样一来，依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。

方法二：
在Alarm接口定义alarm方法，在Door接口定义lock，unlock方法，Door接口继承Alarm接口。


跟方法一同样，依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。违反了ISP原则。

遵循ISP原则的例：


方法三：经过多重继承实现

Adapter设计模式的实现。
第2）种方案更具备实用性。
这种设计遵循了ISP设计原则。

方法四：经过委托实现

在Alarm接口定义alarm方法，在Door接口定义lock，unlock方法。接口之间无继承关系。CommonDoor实现Door接口，
AlarmDoor有2种实现方案：
1）同时实现Door和Alarm接口。
2）继承CommonDoor，并实现Alarm接口。该方案是继承方式的

小结

Interface Segregation Principle (ISP)从对接口的使用上为咱们对接口抽象的颗粒度创建了判断基准：在为系统设计接口的时候，使用多个专门的接口代替单一的胖接口。




四. Single Responsibility Principle (SRP) - 单一职责原则


    永远不要让一个类存在多个改变的理由。换句话说，若是一个类须要改变，改变它的理由永远只有一个。若是存在多个改变它的理由，就须要从新设计该类。

SRP（Single Responsibility Principle）原则的核心含意是：只能让一个类有且仅有一个职责。这也是单一职责原则的命名含义。

为何一个类不能有多于一个以上的职责呢？
若是一个类具备一个以上的职责，那么就会有多个不一样的缘由引发该类变化，而这种变化将影响到该类不一样职责的使用者（不一样用户）：
1，一方面，若是一个职责使用了外部类库，则使用另一个职责的用户却也不得不包含这个未被使用的外部类库。
2，另外一方面，某个用户因为某缘由须要修改其中一个职责，另一个职责的用户也将受到影响，他将不得不从新编译和配置。这违反了设计的开闭原则，也不是咱们所指望的。

职责的划分

既然一个类不能有多个职责，那么怎么划分职责呢？
Robert.C Martin给出了一个著名的定义：所谓一个类的一个职责是指引发该类变化的一个缘由。若是你能想到一个类存在多个使其改变的缘由，那么这个类就存在多个职责。

Single Responsibility Principle (SRP)的原文里举了一个Modem的例子来讲明怎么样进行职责的划分，这里咱们也沿用这个例子来讲明一下：

SRP违反例：
Modem.java
interface Modem {
     public void dial(String pno);     //拨号
     public void hangup();         //挂断
     public void send(char c);     //发送数据
     public char recv();         //接收数据
}

咋一看，这是一个没有任何问题的接口设计。但事实上，这个接口包含了2个职责：第一个是链接管理（dial, hangup）；另外一个是数据通讯（send, recv）。不少状况下，这2个职责没有任何共通的部分，它们由于不一样的理由而改变，被不一样部分的程序调用。
因此它违反了SRP原则。

下面的类图将它的2个不一样职责分红2个不一样的接口，这样至少可让客户端应用程序使用具备单一职责的接口：

让ModemImplementation实现这两个接口。咱们注意到，ModemImplementation又组合了2个职责，这不是咱们但愿的，但有时这又是必须的。一般因为某些缘由，迫使咱们不得不绑定多个职责到一个类中，但咱们至少能够经过接口的分割来分离应用程序关心的概念。
事实上，这个例子一个更好的设计应该是这样的，如图：

小结

Single Responsibility Principle (SRP)从职责（改变理由）的侧面上为咱们对类（接口）的抽象的颗粒度创建了判断基准：在为系统设计类（接口）的时候应该保证它们的单一职责性。


五. The Open-Closed Principle (OCP) - 开闭原则

开闭原则（OCP：Open-Closed Principle）是指在进行面向对象设计（OOD：Object Oriented Design）中，设计类或其余程序单位时，应该遵循：
- 对扩展开放（open）
- 对修改关闭（closed）
 
开闭原则是判断面向对象设计是否正确的最基本的原理之一。 根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该能够在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。
A  扩展开放：某模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。
 B 修改关闭：某模块被其余模块调用，若是该模块的源代码不容许修改，则该模块修改关闭的。软件系统的功能上的稳定性，持续性要求是修改关闭的。

这也是系统设计须要遵循开闭原则的缘由：
1）稳定性。开闭原则要求扩展功能不修改原来的代码，这可让软件系统在变化中保持稳定。
2）扩展性。开闭原则要求对扩展开放，经过扩展提供新的或改变原有的功能，让软件系统具备灵活的可扩展性。
遵循开闭原则的系统设计，可让软件系统可复用，而且易于维护。

开闭原则的实现方法

为了知足开闭原则的 对修改关闭（closed for modification） 原则以及扩展开放（open for extension） 原则，应该对软件系统中的不变的部分加以抽象，在面向对象的设计中，
A 能够把这些不变的部分加以抽象成不变的接口，这些不变的接口能够应对将来的扩展；
B 接口的最小功能设计原则。根据这个原则，原有的接口要么能够应对将来的扩展；不足的部分能够经过定义新的接口来实现；
C 模块之间的调用经过抽象接口进行，这样即便实现层发生变化，也无需修改调用方的代码。

接口能够被复用，但接口的实现却不必定能被复用。接口是稳定的，关闭的，但接口的实现是可变的，开放的。能够经过对接口的不一样实现以及类的继承行为等为系统增长新的或改变系统原来的功能，实现软件系统的柔软扩展。

         简单地说，软件系统是否有良好的接口（抽象）设计是判断软件系统是否知足开闭原则的一种重要的判断基准。如今多把开闭原则等同于面向接口的软件设计。

开闭原则的相对性

软件系统的构建是一个须要不断重构的过程，在这个过程当中，模块的功能抽象，模块与模块间的关系，都不会从一开始就很是清晰明了，因此构建100%知足开闭原则的软件系统是至关困难的，这就是开闭原则的相对性。但在设计过程当中，经过对模块功能的抽象（接口定义），模块之间的关系的抽象（经过接口调用），抽象与实现的分离（面向接口的程序设计）等，能够尽可能接近知足开闭原则。
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程