Java设计模式 之七大设计原则

开闭原则

对扩展开放，对修改关闭。
强调用抽象构建框架，用实现扩展细节。
核心思想是面向抽象编程。

买书案例。

public interface IBook {
    String getName();
    double getPrice();
}
// Java 书籍价格
public class JavaBook implements IBook {
    String name;
    double price;
    @Override
    public String getName() {
        return this.name;
    }
    @Override
    public double getPrice() {
        return this.price;
    }
}

现在我们要对Java书籍打折促销，直接修改 JavaBook 类违反了对修改关闭的原则，直接写一个打折的 Java书籍类。
打折的Java书籍类继承了正常的Java书籍类，然后覆盖了获取价格的方法。

public class JavaDiscountBook extends JavaBook {
    @Override
    public double getPrice() {
        return super.getPrice() * 0.8;
    }
}

6、合成复用原则（Composite Reuse Principle）
原则是尽量使用合成/聚合的方式，而不是使用继承。

依赖倒置原则

针对接口编程，依赖于抽象而不依赖于具体。
高层模块不应该依赖底层模块，都应该依赖其抽象。
可以减少类之间的耦合性，可以降低修改程序所造成的风险。

不使用依赖倒置原则案例：
定义一个驾驶员和比亚迪汽车类。
下面的案例完成了一个名为allen的司机开动比亚迪汽车的场景。

public class Driver {
    public void driver(Byd byd){
        byd.run();
    }
}
public class Byd {
    public void run(){
        System.out.println("Byd run...");
    }
}
public class Client {
    public static void main(String[] args) {
        Driver allen = new Driver();
        Byd byd = new Byd();
        allen.driver(byd);
    }
}

这时 allen 想开宝马车了，那怎么办呢？先定义一个宝马汽车类。
然后发现我们的 allen 没有开动宝马车的方法，显然是不合理的，一个司机怎么可能只会开一个品牌的汽车呢，这时发现是我们设计出问题了，司机类和比亚迪汽车类耦合到一起了，导致了系统的维护性大大降低。
如果为了司机可以宝马汽车，就在司机类上增加开动宝马汽车的方法，这时司机肯定不乐意了，为啥增加一个汽车品牌我就要改动呢，不稳定。

public class Bmw {
    public void run(){
        System.out.println("Bmw run...");
    }
}

public class Driver {
    public void driver(Byd byd){
        byd.run();
    }
    public void driverBmw(Bmw bmw){
        bmw.run();
    }
}

上面的案例证明了，不使用依赖倒置原则就会加重类之间的耦合性，降低系统的稳定性，增加了并行开发引起的风险。
下面我们来引入依赖倒置原则。
分别为司机和汽车抽象出接口。

public interface IDriver {
    void dirver(ICar car);
}

public interface ICar {
    void run();
}

在 IDriver 中，通过传入 ICar 接口实现了抽象之间的依赖关系，Driver 实现类需要开动哪个汽车，传入 ICar 具体的实现类就可以。

public class Driver implements IDriver {
    @Override
    public void dirver(ICar car) {
        car.run();
    }
}
public class Byd implements ICar {
    @Override
    public void run() {
        System.out.println("Byd run...");
    }
}
public class Bmw implements ICar {
    @Override
    public void run() {
        System.out.println("Bmw run...");
    }
}

上面的业务场景中，遵守了 抽象不应该依赖细节，也就是我们认为抽象ICar接口不依赖Bmw和Byd两个实现类，所以在高层次的模块中应用都是抽象。

接口隔离原则

为了解耦，使用多个相互隔离的接口。
使用多个隔离的接口，比使用单个接口要好。
可以降低类之间的耦合度的意思，为了降低依赖，降低耦合。
接口尽量小，这是接口隔离原则的核心定义，不出现臃肿的接口，但是 小 是有限度 的，首先就是不能违反单一职责原则。

违反接口隔离原则案例：
定义一个动物接口，不同动物有不同的行为，包括：吃、飞、游泳。

public interface IAnimal {
    void eat();
    void fly();
    void swim();
}

实现一个鸟和狗类，发现鸟类中有游泳的行为，狗有飞的行为，显然这是不合理的。

public class Bird implements IAnimal {
    public void eat() { }
    public void fly() { }
    public void swim() { }
}

public class Dog implements IAnimal {
    public void eat() { }
    public void fly() { }
    public void swim() { }
}

使用接口隔离原则重新定义接口：
不同行为分别定义自己的接口，使一个接口只负责一个特定的行为，不要和其他行为耦合。

public interface IEatAminal {
    void eat();
}
public interface IFlyAminal {
    void fly();
}
public interface ISwimAminal {
    void swin();
}

再次定义鸟和狗类，这时每个类实现我需要的行为接口即可，不会耦合到我不需要的行为。

public class Bird implements IEatAminal,IFlyAminal {
    public void eat() { }
    public void fly() { }
}
public class Dog implements ISwimAminal,IEatAminal {
    public void eat() { }
    public void swin() { }
}

单一职责原则

一个类、接口、方法只负责一项职责。
一个方法尽可能做一件事，比如一个方法修改用户密码，不要把这个方法放到 修改用户信息 方法中。

在 IUserManager 中定义了一个方法改变用户信息，根据传递不同类型来判断对应的用户信息，职责不明确，不单一。

修改用户名称，修改家庭地址都分别定义不同的方法，职责非常清晰，不仅开发简单，维护和非常容易。

里氏代换原则

里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科

迪米特法则

一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
尽量使用合成、聚合的方式，而不是使用继承。