深入浅出设计模式——接口隔离原则

1.接口隔离原则介绍

2.用代码演示接口隔离原则

3.总结

1.接口隔离原则介绍
定义：客户端不应该依赖它不需要的接口，即一个类对应另一个类的依赖应建立在最小的接口之上。

问题描述：假设我们有一个用户UserService,里面除了能够查询User信息等基本操作，还能统计User分布地，User登录习惯，User性别占比情况，User消费习惯等数据，如果将这些所有功能全都放在UserService里，显然不合理，

解决办法：正确的做法是讲他们隔离开，UserService应当拆分成两个，UserInfoService和UserCalculateService（用户统计service）两个类，因为查询用户信息的controller依赖UserService的时候，只依赖了查询用户信息的那几个方法，查询统计报表信息的时候，只依赖了UserCalculateService的那几个方法。

2.用代码演示接口隔离原则

假设我们有一个UserService:

public interface UserService {

    //获取用户姓名信息
    public String getUserName(String userId);
    //获取用户年龄信息
    public Integer getUserAge(String userId);
    //获取用户所有信息
    public String getUserMsg(String userId);

    //统计用户年龄分布情况
    public String calculateUserAgeDistribution(String userId);
    //统计用户消费情况
    public String calculateUserConsumerDistribution(String userId);

}

可以看出，接口过于臃肿，依赖这个接口的实现类，不管对于依赖它的类有没有用处，实现类中都必须要实现这些方法。

如果根据接口隔离原则的设计方法，我们队接口进行拆分，拆为两个接口，如下图所示：

3.总结

可能会有很多人觉得接口隔离就是之前的单一职责，其实有以下的区别：
1）单一职责的侧重点是功能的单一性，而接口隔离侧重于对接口依赖性的隔离。
2）单一职责原则主要的对象是类和方法，而接口隔离的主要对象是接口，是抽象层面的东西。

采用接口隔离原则的注意事项：

1）接口在一定程度范围内尽量要小，但是如果过小会妨碍编码，要走中庸之道。

2）类的接口一定要只为一个模块提供服务，尽量少暴露最接口。

3）设计的时候多思考，不断实践，才能领会这一原则。