记在前面：这个《设计模式》系列的文章，想了很久才决定写的，一是还是本人的原则，只有通过自己表达出来的东西，才是真正属于你的东西，所以即使写的不好，有什么理解不到位的，被人指出来也挺好的，证明属于我的东西还是有缺漏嘛。二是设计模式这个东西有点虚，特别这篇原则，总觉得还欠缺很多理解。三是看了好几篇设计模式，下面的讨论基本分两种，要么就是一堆Mark，要么就是一堆FXXk，也是有点担心会被骂吧，不过错了被指正也是很正常。不说废话了，上正文。
本文属于系列文章《设计模式》，附上文集链接

一. 单一职责原则

• 定义：不要存在多于一个导致类变更的原因。简单说，就是一个类只负责一项职责。
• 为什么要这个原则：试想，一个类T，用来实现两个职责t1和t2，在需求变更的情况下需要修改t1，可能导致原本正常工作的t2职责出错。

但是这个原则，其实看到的话，很多人应该都会觉得没啥好看的吧，因为太简单了，而且在写代码的时候，应该都不希望因为修改了一个功能导致其他的功能发生故障。
但是翻了好几篇博客，还有看到的书的作者也是说到，其实并没有很多类设计能完全遵守到单一职责原则，因为这个原则受太多因素制约了，比如下面这个例子：

我们要造车，然后要车跑起来

public class Car {
    public void run(String carType){
        System.out.println("启动"+carType+"引擎跑起来了");
    }   
}
public class Client {
    public static void main(String[] args) {
        Car c = new Car();
        c.run("BMW");
        c.run("Benz");
    }
}
结果：
  启动BMW引擎跑起来了
  启动Benz引擎跑起来了

后面发现还有类似上世纪的小包车这种需要拉才能跑起来的车，我们怎么办呢？
首先按照单一职责原则，我们来另起一个类，来实现这个功能

public class Trolley {
    public void run(String carType){
        System.out.println("拉着"+carType+"跑起来了");
    }
}
public class Client {
    public static void main(String[] args) {
        Car c = new Car();
        c.run("BMW");
        c.run("Benz");
        Trolley trolley = new Trolley();
        trolley.run("上世纪的小包车");
    }
}
结果：
启动BMW引擎跑起来了
启动Benz引擎跑起来了
拉着上世纪的小包车跑起来了

但是这里就有一个问题了，如果后期还有斗车这种要推的车，还有自行车这种要骑的车，还有几十种其他的车，那我们难道要一个类一个类的写吗？这样会造成类膨胀的。而且修改了类，还得大幅度修改客户端
所以在这里，再引入这个原则的同时，就得违背下这个原则了，如下:

public class Car {
    public void run(String carType){
        System.out.println("启动"+carType+"引擎跑起来了");
    }
    public void run2(String carType){
        System.out.println("拉着"+carType+"跑起来了");
    }
}
public class Client {
    public static void main(String[] args) {
        Car c = new Car();
        c.run("BMW");
        c.run("Benz");
        c.run2("上世纪的小包车");
    }
}
结果：
启动BMW引擎跑起来了
启动Benz引擎跑起来了
拉着上世纪的小包车跑起来了

这样做的一个好处就是方便，直接在类里面新添加一个方法，在客户端只需要做小小的改动就可以用。这只是其中一个办法，当然，还有很多种办法，比如在run方法中根据carType判断来选择方式等等，但是这都违背了单一职责原则。所以这个原则怎么用呢？个人理解，很多时候我们在实际的编码过程中并不能完全遵守这个原则，我们只能尽量做到这个原则。不然的话就是死守教规了。

二. 里氏替换原则

• 定义：所有引用父类的地方必须能透明地使用其子类的对象。

• 为什么要用这个原则：试想一下，在一个类P1中，实现了方法m1，然后现在需要扩展m1方法，新的方法m2由P1的子类来完成，在完成m2的同时，有可能会将m1的方法破坏掉，使得m1不能正常工作。

上代码,还是用上文的例子：

public class Car {
    public void run(String carType){
        System.out.println("启动"+carType+"引擎跑起来了");
    }
}
public class Client {
    public static void main(String[] args) {
        Car c = new Car();
        c.run("BMW");
    }
}
结果：
启动BMW引擎跑起来了

现在需要加一个功能，就是对行车的速度进行汇报，怎么做？首先想到的是不是直接修改Car的run方法，但是要注意，这个不是一个好的方法，修改了这个run方法，可能会导致本来在使用这个方法的其他对象产生错误的结果，所以不能这样，我们使用继承，然后重写run方法，如下：

public class AdvancedCar extends Car{
    @Override
    public void run(String carType) {
        super.run(carType);
        System.out.println("车的速度是80KM/h");
    }
}
public class Client {
    public static void main(String[] args) {
        AdvancedCar car = new AdvancedCar();
        car.run("BMW");
    }
}
结果：
启动BMW引擎跑起来了
车的速度是80KM/h

然后这里的确实现了功能，而且代码还很整洁，只是一个继承然后加多一句就好了，但是问题就来了，假设再来需求，上班高峰期的时候塞车，不需要汇报速度，下班加班赶回家才需求汇报速度（保平安嘛），那咋办？在这个AdvancedCar中，run方法一经调用，就会汇报速度的喔。用里氏替换原则来看，Car出现的地方，AdvancedCar就不能用了，我们来用里氏替换原则修改下代码：

public class AdvancedCar extends Car{
    public void showSpeed(){
        System.out.println("车的速度是80KM/h");
    }
}
public class Client {
    public static void main(String[] args) {
        AdvancedCar car = new AdvancedCar();
        car.run("BMW");
        car.showSpeed();
    }
}
结果：
启动BMW引擎跑起来了
车的速度是80KM/h

这样修改之后，Car出现的地方，AdvancedCar也能直接使用，因为run方法的原有功能并没有被破坏，而且要满足上一段需求的话，只需要直接在Client这里加判断就好。
所以我自己的粗略理解就是：子类可以扩展父类的方法，但不应该复写父类的方法。

三. 依赖倒置原则

• 定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

• 为什么要用这个原则：假设一个类P组合了一个类A，然后用A实现了相关的功能，然后现在要将A实现的功能改成B类来实现，这里的修改方法是只能去修改P的代码，而这种直接修改代码是会带来不必要的风险的。

上例子,还是用车的例子：

public class Car {
    // 给汽车加油
    public void refuel(Gasoline90 gasoline){
        System.out.println("加了型号为"+gasoline.getClass().getSimpleName()+"的汽油");
    }
}
public class Gasoline90 { }
public class Client {
    public static void main(String[] args) {
        Car car = new Car();
        car.refuel(new Gasoline90());
    }
}
结果：
加了型号为Gasoline90的汽油

现在问题来了，加油站没有90汽油了，只有93和97，而汽车没油了，难道但是加油refuel(Gasoline90 gasoline)只能加90汽油，咋办,难不成直接修改car的代码，给它多加两个方法，分别可以加93和97汽油？很明显不科学嘛，一点代码复用都没有，更别谈设计模式了，所以在这里，就要改了。

// 定义一个接口Gasoline
public interface Gasoline { }

//在Car类的refuel方法中传入Gasoline参数
public class Car {
    public void refuel(Gasoline gasoline){
    System.out.println("加了型号为"+gasoline.getClass().getSimpleName()+"的汽油");
    }
}

// 写90和97两个汽油的类
public class Gasoline90 implements Gasoline{ }
public class Gasoline97 implements Gasoline{ }

// 场景
public class Client {
    public static void main(String[] args) {
    Car car = new Car();
 //car.refuel(new Gasoline90());
    System.out.println("----汽车站没有90汽油了-----");
    car.refuel(new Gasoline97());
    }
}

结果：
----汽车站没有90汽油了-----
加了型号为Gasoline97的汽油

在上面的例子，传参的时候传入了一个Gasoline类型，只要汽车要加的汽油，全都实现这个借口，就可以让汽车自由加油，管它什么93,97,1997都好，而且还不用修改Car的代码，只需要实现Gasoline接口就好。

四. 接口隔离原则

咋看一下，我以为像现实生活中那样，隔离病原体是把病原体隔离开来，那接口隔离原则难道是隔离接口？编程界的名词确实不能一般对待。

• 定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上
• 为什么需要这个原则：假想我们设计了一个接口I，里面有五个方法，分别是m1,m2,m3,m4,m5，而有两个类A和B，分别需要用m1m2m5,m3,m4,m5方法。那么无论是那一个类，在实现接口I的时候，都要将其本身不需要的类进行实现，很明显，这不是一个好设计。
  上代码，还是用车的例子：

// 接口
public interface ICar {
    public void run(String carType);
    public void showSpeed();
    public void playMusic(String songName);
}

// 实现类
public class Car implements ICar{
    public void run(String carType){
     System.out.println("启动"+carType+"引擎跑起来了");
    }
    public void showSpeed() {
     System.out.println("汽车的速度为80KM/h");
    }
    public void playMusic(String songName) {
    System.out.println("放起了动听的"+songName);
    }
}

// 场景
public class Client {
    public static void main(String[] args) {
    Car car = new Car();
    car.run("BMW");
    car.showSpeed();
    car.playMusic("成都");
    }
}

这里问题就来了，并不是所有的车都有放音乐的功能，也并不是所有的车都有展示速度的功能，但是只有上面代码这个车的话，我们在新建其他车对象的时候，却带上了全部的功能，显然，这是不科学的。改进下，将上面的接口拆分成两个接口专业的车IProfessionalCar和娱乐功能的车IEntertainingCar

// 接口
public interface IProfessionalCar {
    public void run(String carType);
    public void showSpeed();
}
public interface IEntertainingCar {
    public void run(String carType);
    public void playMusic(String songName);
}

// 实现类
public class ProfessionalCar implements IProfessionalCar {
    public void run(String carType){
    System.out.println("启动"+carType+"引擎跑起来了");
    }
    public void showSpeed() {
    System.out.println("汽车的速度为80KM/h");
    }
}
public class EntainingCar implements IEntertainingCar {
    public void run(String carType){
    System.out.println("启动"+carType+"引擎跑起来了");
    }
    public void playMusic(String songName) {
    System.out.println("放起了动听的"+songName);
    }
}

// 场景
public class Client {
    public static void main(String[] args) {
    IProfessionalCar professionalCar = new ProfessionalCar();
    professionalCar.run("F1方程式");
    professionalCar.showSpeed();
    EntainingCar entainingCar = new EntainingCar();
    entainingCar.run("坏了速度仪表盘的SUV");
    entainingCar.playMusic("成都");
    }
}
结果：
启动F1方程式引擎跑起来了
汽车的速度为80KM/h
启动坏了速度仪表盘的SUV引擎跑起来了
放起了动听的成都

接口隔离原则的要求我们，建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。这通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

五. 迪米特法则

• 定义：一个对象应该对其他对象保持最少的了解。
• 为什么需要这个原则：原因就是一个对象对另一个对象了解得越多，那么，它们之间的耦合性也就越强，当修改其中一个对象时，对另一个对象造成的影响也就越大。

上例子，还是用车：

// 车
public class Car {
    private String carType;
    public Car(String carType){
        this.carType = carType;
    }
    public void run(){
        System.out.println("启动"+carType+"引擎跑起来了");
    }
    public void refuel(Gasoline gasoline){
        System.out.println("加了型号为"+gasoline.getName()+"汽油");
    }
}
// 汽油
public class Gasoline {
    private String name;
    public Gasoline(String name) {
        this.name = name;
    }
    public String getName() {
        return name;
    }
    private boolean quality = true;
    public boolean getQuality(){
        return this.quality;
    }
}
// 人
public class Person {
    private Car car;
    public void setCar(Car car) {
        this.car = car;
    }
    public void drive(){
        car.run();
    }
    public void refuel(Gasoline gasoline){
        if(gasoline.getQuality()){
            System.out.println("油的质量过关，可以放心加");
            car.refuel(gasoline);
        }
}
// 场景类
public class Client {
    public static void main(String[] args) {
        Person jack = new Person();
        jack.setCar(new Car("Suv"));
        jack.drive();
        System.out.println("*********开了三百公里，没油了********");
        jack.refuel(new Gasoline("90"));
    }
}
结果：
启动Suv引擎跑起来了
*********开了三百公里，没油了********
油的质量过关，可以放心加
加了型号为90汽油

我们可以看到，一个很符合生活的场景，jack开车，然后开太久了，没油了，于是加油，但是问题就来了，在生活中，加油这个动作应该是jack和加油站的工作人员进行交涉，然后由加油站的工作人员来完成，而在上面这里，则是由jack自己完成。而且对油的质量的检验，我们普通人怎么会，肯定不行啊，万一90,93,97的检验方法各不相同，万一以后的油质量越来越不好，检验步骤要变，难道要修改Person类的方法，不对啊。
我们来改下

// 增加类加油站工人
public class WorkerInPetrolStation {
    public void refuel(Car car, String gasolineName) {
    Gasoline gasoline = new Gasoline(gasolineName);
    if (gasoline.getQuality()) {
    System.out.println("油的质量过关，可以放心加");
    car.refuel(gasoline);
    }
    }
}
// 将Person的refuel方法修改成依赖工人
public class Person {
    private Car car;
    public void setCar(Car car) {
    this.car = car;
    }
    public void drive(){
    car.run();
    }
    public void refuel(WorkerInPetrolStation worker, String gasolineName){
    worker.refuel(this.car, gasolineName);
    }
}
// Car，Gasoline不变
// 场景类
public class Client {
    public static void main(String[] args) {
    Person jack = new Person();
    jack.setCar(new Car("Suv"));
    jack.drive();
    System.out.println("*********开了三百公里，没油了********");
    jack.refuel(new WorkerInPetrolStation(),"90");
    }
}
结果：
启动Suv引擎跑起来了
*********开了三百公里，没油了********
油的质量过关，可以放心加
加了型号为90汽油

现在无论以后油那边怎么变，都和我们Persion无关，交给加油站工人嘛，这是他们的饭碗。
迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系。过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。

六. 开闭原则

• 定义：对修改关闭，对扩展开放
• 为什么使用这个原则：这不就是代码重用的一个终极目标吗，不实现这个原则，改代码改到怀疑人生啊！而上面的五个原则，其实就是这个原则的体现。
  但是这个原则，正是因为太高级了，所以太虚了，虚的没什么套路可寻，只能靠经验，领悟来慢慢体会。

总结：

以上就是我对这六个原则的简单理解，例子也不知道举得恰不恰当，文字的描述也不知道是不是到位，但是这也就是我的理解了，等深入这行有一定时间，或许会对这篇东西觉得很傻，噗嗤一声，完全不屑。但也是以后的事了。
欢迎前来责骂。。。