设计模式六大原则

1、介简

面向对象OOP的开发模式中，不论从事的是后台还是前端开发，都离不开设计模式的制约。不论什么框架和架构，都离不开设计模式的约束。OOP设计模式有六大原则，现在就来谈谈这六大原则、这些原则的优点，以及平时编码过程中是如何按照这六大原则来进行设计的。

1.1 单一职责原则

“改变一个类的原因不能超过一个”该原则面向的对象是类。
以Car这个类为例，它有move这个功能：

public class Car {
    private void move() {
        System.out.println("move");
    }
}

车辆还有载人功能，把load功能也加到Car里面：

public class Car {
    private void move() {
        System.out.println("car move");
    }

    private void load() {
        System.out.println("car load");
    }
}

这样一来，Car有两个功能，一个是move，一个是load。问题来了，修改move的时候，Car这个类就会变动；修改load的时候，Car这个类也会变动。那Car这个类是否可以拆分成两个类呢？答案是可以。Car如果依赖了其他类，例如：

public class Car {
    private Driver driver;

    private void init() {
        driver = new Driver();
    }

    private void move() {
        System.out.println("move");
    }
}

假设给这辆车配备司机，开始对司机进行初始化。但是Driver这个类的初始化，本身不应该在Car这个类里面进行。也就是说，Car这个类没有职责去初始化所依赖的Driver类（可以用工厂模式等去实现）。因此，像Dagger2这样的框架解决的就是这类单一职责的问题。

1.2 里氏替换原则

“使用基类的地方如果替换成子类，不影响当前功能的实现。”该原则面向的对象是子类和父类。
具体表现如下：

• 子类继承父类后，可以扩展父类功能。

• 子类可以实现父类抽象的方法，但是不能覆盖父类已实现的方法。
  简而言之，里氏替换原则说明的是：子类可以对父类进行扩展，但是不能改变父类现有的功能。
  还是以Car这个类为例，现在由Benz子类继承它：

  public class Benz extends Car {
      private void newMove() {
          System.out.println("benz move");
      }
  }
  

注：：子类增加自己特有的方法，不用覆盖父类实现的方法。

1.3 依赖倒置原则

“所有模块必须依赖抽象，实现也依赖抽象。”
该原则面向的对象是模块之间的。
具体表现如下：

• 底层模块：原子逻辑，不可分割的业务逻辑。

• 高层模块：原子逻辑的封装。

• abstractions：接口或抽象类，不能被直接实例化。

• details：接口或抽象类的实例化。
  简而言之就是面向接口编程。
  举例来说，Benz这辆车由司机来开，这里把司机叫作ZhangSan：

  public class Benz {
      public void move(ZhangSan zhangsan) {
         System.out.println("driver is ZhangSan");
      }
  }
  
  public class Client {
      public static void main(String[] args) {
          Benz benz = new Benz();
          Zhangsan zhangsan = new ZhangSan();
          benz.move(zhangsan);
      }
  }
  

可以看到Benz这辆车配备了一个叫作ZhangSan的司机，而且只能由叫作ZhangSan的司机来驾驶。万一有一天ZhangSan请假了，这辆Benz车那不是就不能开动了？现实是只要拥有符合条件的驾照的驾驶员就可开Benz这辆车，那么Benz的drive方法中就不能限制只对ZhangSan这个驾驶员有效。
定义一个接口，这个接口中有个granted方法，任何实现了这个方法的驾驶员都有权限开Benz这辆车。

  public interface ILicense {
      void granted();
  }
  public class LiSi implements ILicense {
      public boolean granted() {
          System.out.println("driver with license");
          return true;
      }
  }
  public class Benz {
      public void move(ILicense license) {
          if (license.granted()) {
              ...
          }
      }
  }

定义了LiSi，拥有驾照，那么这辆Benz车不再是只能由ZhangSan来驾驶了：

  public class Client {
      public static void main(String[] args) {
          Benz benz = new Benz();
          ILicense license = new LiSi();
          benz.move(license);
      }
  }

1.4 接口隔离原则

“类和类之间应该保持最小程度的依赖。”
该原则面向的对象是类和接口。
该原则说明类实现的接口应该是这个类所需要的。换句话说，定义接口时，应当做到尽量根据业务逻辑细化。
例如：IMove接口表示能动的物体。如果是飞机呢？飞机能飞，于是IMove接口增加了fly方

  public interface IMove {
      void move();

      void fly();
  }

这样一来，Benz implements IMove接口实现后，还需要实现fly方法，虽然这个方法里面也可不做处理，但是这样会增大代码的冗余度，提升阅读难度。因此fly这个方法应该放到其他供飞机使用的接口中。

1.5 迪米特法则

“只和你亲近的朋友交谈。”
该原则描述得很形象，就是说一个类尽可能少地使用暴露方法，能用private的就用private，尽可能少地让外界调用到你的方法。该原则面向的对象是类和类之间的。
具体表现如下：

• private方法主要实现类本身的逻辑功能。
• protected方法主要暴露给子类用。
• public方法主要是给其他类提供接口。
  我们可以用一句话概括这个原则：高内聚，低耦合。

1.6 开闭原则

“软件实体，如类、模块、函数应该对扩展开放，对修改关闭。”
面向的对象：类、模块、函数。这个原则在工厂方法设计模式中体现得很明显。
还是以上面的Benz类为例：

   public class Benz implements IMove {
       public void move(ILicense license) {

       }
   }

如果现在要实现一辆赛车版的Benz，它的move有赛车版的功能，现在有以下两种方法来实现。

• IMove里面增加一个raceMove()接口来处理赛车驾驶事宜。

• 在现有的drive方法里面根据传入的参数判断是否为赛车版的Benz，然后进行处理。
  但是这样的处理涉及接口的更改，还有就是对源代码的改动，这些都不是很好的方法，搞不好会对原有功能造成损害。
  使用开闭原则的解决方案就是，新建一个RaceBenz类，继承Benz类，并且在RaceBenz类里面新增一个raceDrive方法：

  public class RaceBenz extends Benz {
      public void raceDrive(ILicense license) {
  
      }
  }