接口隔离原则

接口隔离原则

客户端不应该依赖于它不使用的方法，一个类对另一个类的依赖应该建立在最小的接口上

例如我们现在有两个类：

其中A类里存在方法一和方法二：

//A.class
public void A1() {
    //do sth
}
public void A2() {
    //do sth
}

B类需要使用A类中的方法A1，所以直接依赖于A

//B.class
class B extends A {
    //do sth
}

这样看似实现了功能，B中可以直接调用A中的A1方法。

但B在继承A类时，并不只拥有了A1方法，它同样有了它不需要的A2方法，这就显得很多余了。

现在我们做出改进，将两个方法分开，分别写在两个接口中：A接口和B接口

interface A {
    public void A1;
}

interface B {
    public void A2
}

这样就实现了接口的隔离，当B类需要使用方法一时，它只需要实现A接口：

//B.class
class B implements A {
    public void A1() {
        //do sth
    }
}

如果有一天B类还需要方法二，那么只需要再去实现方法二即可，二者分离实现自由选取，自由搭配，符合了接口隔离原则！

🌰举个例子

我们现在要创建一个防盗安全门，其具有防火、防水、防盗的功能，我们就可以将防火、防水、防盗三个功能提取成一个接口，形成一套规范，类图如下：

接口定义如下：

public interface SafeDoor {
    //防盗
    void antiTheft();
    //防水
    void fireProof();
    //防火
    void waterProof();
}

建造安全门类：

//MySafeDoor
public class MySafeDoor implements SafeDoor {
    public void antiTheft() {
        System.out.println("防盗");
    }
    
    public void fireProof() {
        System.out.println("防火");
    }
    
    public void waterProof() {
        System.out.println("防水");   
    }
}

现在，我们就获得了一个全能三防安全门。

但如果我们现在要新加一个安全门类型，只能防火防盗，并不能防水的产品，接口却提供了三个方法，新产品类就被迫依赖了自己并不需要的防水方法，这就不太合适咯！

我们进行修改：

将三个方法拆分成三个接口，产品就可以根据自身需求来依赖对应的接口！

public interface AntiTheft {
    //防盗
    void antiTheft();
}
​
public interface FireProof {
    //防火
    void waterProof();
}
​
public interface WaterProof {
    //防水
    void fireProof();
}

这样新产品就可以这么写：

public class NewSafeDorr implements AntiTheft,FireProof {
    public void antiTheft() {
        System.out.println("防盗");
    }
    
    public void fireProof() {
        System.out.println("防火");
    }
    
}

这样就完美符合了接口隔离原则！