设计模式六大原则

1. 单一职责模式

单个类保持功能尽量单一，如果组合了多个功能，需要抽象出多个接口，对外提供单一视图。

这样做的好处很多，包括：

• 类的复杂度降低，实现什么职责都有了清晰的定义，因此也提高了可读性
• 可维护性提高，更易于扩展
• 变更风险小，如果接口的单一职责明确，修改接口只会对实现类产生影响，而不会影响其他接口

1. 里氏替换原则

面向对象中，继承是必不可少且非常优秀的语言机制，有很多优点：

• 代码共享，减少创建类的数量
• 提高代码可重用性
• 子类形似父类，但又异于父类
• 提高代码可扩展性，提高代码开放性

但也有一些缺点：

• 继承是侵入性的，只要继承了，就必须拥有父类的所有属性和方法
• 降低代码灵活性，子类必须继承父类的方法和属性，减少了编码自由度
• 增强了耦合性，当父类代码被修改时，就必须考虑子类的修改，如果缺乏规范，可能导致大规模重构。

为了弥补这些缺点，引入了里氏替换原则，定义：所有引用父类的地方必须能够透明的使用其子类的对象。

1. 依赖倒置原则（面向接口编程）

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

　　　　在java语言中，抽象就是指接口或抽象类，细节就是两者各自的实例化类，可以使用new关键字，这个原则可表述为：

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

//定义司机接口
public interface IDrive{
      public void drive(ICar car);
}
public class Driver implements IDrive{
       public void drive(ICar car){
            car.run();
       }
}
//定义车辆接口          
public interface ICar{
       public void run();
}
public class Benz implements ICar{
    public void run(){
        System.out.println("奔驰开动了");
    }
}
public class BWM implements ICar{
    public void run(){
        System.out.println("宝马开动了");
    }
}
public class Client{
    public static void main(String[] args){
        IDriver zhangsan = new Driver();
        ICar benz = new Benz();
        zhangsan.drive(benz);
    }
}

　　依赖有三种写法：构造函数注入，setter方法注入，接口声明依赖对象。

　　

/**构造函数注入*/
public interface IDriver {
//是司机就应该会驾驶汽车
public void drive();
}p
ublic 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();
}p
ublic class Driver implements IDriver{
private ICar car;
public void setCar(ICar car){
this.car = car;
}/
/司机的主要职责就是驾驶汽车
public void drive(){
this.car.run();
}
}
/**接口依赖注入*/
比如上个例子的方法

• 　　最佳实践

依赖倒置原则的本质是使各个模块之间相互独立，互不影响，实现模块间的松耦合，如何实现呢？只需要遵守以下规则：

• 每个类或者模块都有接口或抽象类
• 变量的类型尽量是接口或抽象类，工具类和使用clone()方法的类除外
• 任何类都不应该从具体的实现类中派生，特别的情况除外，比如维护工作，或无法获得父类代码
• 尽量不要覆写基类的方法。如果基类是一个抽象类，且方法已经实现了，子类尽量不要覆写，会影响类之间的依赖稳定性
• 结合里氏替换原则，得到一个通俗规律：接口负责定义公共属性和方法，并且声明和其他类之间的依赖关系；抽象类负责公共构造部分的实现，其实现类准确实现业务逻辑，适时地对父类进行细化扩展。

1. 接口隔离原则

简而言之，就是每个模块尽量分散定义专门的接口，而不是一个臃肿的大一统接口，预防未来业务变更，提高系统灵活性和可维护性。接口定义的数量和类型，视具体业务而定，但接口中的方法必须精要。

1. 迪米特原则

也称为最少知识原则，表示的是一个对象应该对其他对象有最少的了解，也就是说，一个类应该对自己调用的类的实现细节，知道的越少越好。

1. 开闭原则

即软件实体应该对扩展开放，对修改关闭。就是说一个软件实体应该通过扩展实现变化，而不是直接修改已有代码实现变化。软件实体包括功能模块，类或抽象，方法。

这个原则非常重要，是上述五个原则的基础，那么如何使用开闭原则？

• 抽象约束

第一，通过抽象类或接口约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的Public方法；第二，参数类型、引用对象尽量使用抽象类或者接口，而不是实现类；第三，接口和抽象类尽量保持稳定，一旦确定便不允许修改，修改契约就等于让其他模块都改动。

• 元数据控制模块行为

什么是元数据？用来描述环境和数据的数据。通俗来说就是配置参数，包括从配置文件中或数据库中拿到的参数。

• 制定项目章程
• 封装变化

第一，将相同的变化封装到一个接口或抽象类中；第二，将不同的变化封装到不同的接口或抽象类中，不应该出现相同的接口或抽象类出现不同的变化。23个设计模式正是从不同角度来封装变化的。