6个设计原则

单一职责原则

接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

里氏替换原则

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

即：只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。

子类必须完全实现父类的方法

如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。

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

依赖倒置原则

即面向接口编程。

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

依赖的三种写法

构造函数传递依赖对象

public interface IDriver {
  //是司机就应该会驾驶汽车
  public void drive();
}
public class Driver implements IDriver{
  private ICar car;  
  //构造函数注入
  public Driver(ICar _car){
           this.car = _car;
  }
  //司机的主要职责就是驾驶汽车
  public void drive(){
          this.car.run();
  }
}

Setter方法传递依赖对象

public interface IDriver {
  //车辆型号
  public void setCar(ICar car);
  //是司机就应该会驾驶汽车
  public void drive();
}
public class Driver implements IDriver{
  private ICar car;  
  public void setCar(ICar car){
          this.car = car;
  }
  //司机的主要职责就是驾驶汽车
  public void drive(){
          this.car.run();
  }
}

接口声明依赖对象（接口注入）

public interface IDriver {
  //是司机就应该会驾驶汽车
  public void drive(ICar car);
}
public class Driver implements IDriver{    
  //司机的主要职责就是驾驶汽车
  public void drive(ICar car){
          car.run();
  }
}

接口隔离原则

建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。

与单一职责原则不同。
单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分。
而接口隔离原则要求接口的方法尽量少。
例如一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问”。
按照单一职责原则是允许的，按照接口隔离原则是不允许的。

因为接口隔离原则要求“尽量使用多个专门的接口”。
专门的接口指什么？就是指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。

根据接口隔离原则拆分接口时，首先必须满足单一职责原则。

迪米特法则

一个对象应该对其他对象有最少的了解。
通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。

23种设计模式

门面模式（外观模式）

通过controller层去调用service层，通过service层去调用dao层，就是采用了门面模式。