携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第6天，点击查看活动详情
简介
接口隔离的原则定义是：
1、一个类不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上
2、一个类对另外一个类的依赖性应当是建立在最小的接口上的
相对其他原则，接口隔离原则从定义上看就比较好理解，咱们直接上案例。
案例
我们一般情况下使用SpringBoot开发常规应用，会对代码进行Controller、Service、Mapper三层，一般在Service业务层我们会定义一个Service,一个对Service的实现供Controller层调用。
如UserService和UserServiceImpl，通常我们会将有关User操作和查询的业务方法都写在这个UserService里，然后通过注入UserMapper和其他Mapper配合来实现相关业务逻辑。如下：
public interface UserService {
/**
* 获取单个用户
* @return
*/
User getOneUser();
/**
* 新增用户
* @return
*/
Long addUser();
/**
* 修改用户
* @return
*/
Integer updateUser();
/**
* 删除用户
* @return
*/
Integer deleteUser();
/**
* 获取用户列表
* @return
*/
List<User> getUserList();
/**
* 后管分页获取用户
* @return
*/
Page<User> getUserPageForBackend();
/**
* APP端分页获取用户
* @return
*/
Page<User> getUserPageForApp();
/**
* 导出用户到excel
* @return
*/
List<User> exportUserToExcel();
/**
* 导出用户到txt
* @return
*/
List<User> exportUserToTxt();
/**
* json格式导出用户
* @return
*/
List<User> exportUserToJson();
}
UserServiceImpl类实现上面的UserService的所有方法，在此就不贴代码了。
从上面的代码能看出，我们将所有和User相关的各种方法放在了UserService里，在我们只是写了方法的定义的情况下，这个类已经显得十分臃肿，要是我们后续在各个方法里在加上业务逻辑，那这个类看起来就非常不整洁了。各个方法之间耦合太紧密，比较难维护。这个一个典型的违背接口隔离原则的模式。
按照接口给力原则，我们可以将有关User的各个业务方法进行分类，如增删改的作为一个UserService，用户信息查询的定义为UserQueryService，导出相关的则定义一个UserExportService。。。登录就只依赖登录的接口，导出只依赖导出的接口等等。
1、用户增删改接口
public interface UserService {
/**
* 新增用户
* @return
*/
Long addUser();
/**
* 修改用户
* @return
*/
Integer updateUser();
/**
* 删除用户
* @return
*/
Integer deleteUser();
}
2、用户查询接口
public interface UserQueryService {
/**
* 获取单个用户
* @return
*/
User getOneUser();
/**
* 获取用户列表
* @return
*/
List<User> getUserList();
/**
* 后管分页获取用户
* @return
*/
Page<User> getUserPageForBackend();
/**
* APP端分页获取用户
* @return
*/
Page<User> getUserPageForApp();
}
3、用户导出相关接口
public interface UserExportService {
/**
* 导出用户到excel
* @return
*/
List<User> exportUserToExcel();
/**
* 导出用户到txt
* @return
*/
List<User> exportUserToTxt();
/**
* json格式导出用户
* @return
*/
List<User> exportUserToJson();
}
重构之后每个接口都承担自己范围的的功能与职责，通过名字就能很清晰地明白这个类是功能是什么，而且灵活性很高，使用起来很方便，每个接口中都只包含和自己业务相关的方法，不会存在和自己无关的方法，达到了高内聚、松耦合的效果。
总结
此原则的含义也比较好理解，相信大家通过这个例子应该能在一定程度上对接口隔离有些清晰了。当然我们在实战中对接口隔离原则并不是要生硬地套用，在有些情况下我们要控制好接口的颗粒度，不能太大也不能太小，否则接口太多也会造成泛滥，给后续维护带来不便，这就违背了我们接口隔离原则的初衷了。
至此，咱们设计模式的六大设计原则我们就全部梳理了一遍，我觉得我自己对设计模式的理念还是有了更深的理解的，后续我们将真正开始23个设计模式的学习和回顾。
