我们可以把这两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。看到这里大家有可能要疑惑了，这与单一职责原则不是相同的吗？错，接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问”，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”,专门的接口指什么？就是指提供给每个模块都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。
接口隔离原则是对接口进行规范约束，其包含以下四层含义：
接口尽量要小。根据接口隔离原则拆分接口时，必须首先满足单一职责原则。
接口要高内聚
定制服务
接口设计是有限度的
一个接口只服务于一个子模块或者业务逻辑
通过业务逻辑压缩接口中的public方法
已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。
了解环境，拒绝盲从
接口隔离原则和其他的设计原则一样，都是需要花费较多的时间和精力来进行设计和筹划，但是它带来了设计的灵活性，让你在业务人员在提出“无理”要求的时候可以轻松应付。贯彻使用接口隔离原则最好的方法就是一个接口一个方法，保证绝对符合接口隔离原则（有可能不符合单一职责原则），但你会采用吗？！不会，除非你是疯子！那怎么才能正确的使用接口隔离原则呢？ 答案是根据经验和常识决定接口的粒度大小，接口粒度太小，导致接口数据剧增，开发人员呛死在接口的海洋里；接口粒度太大，灵活性降低，无法提供定制服务，给整体项目带来无法预计的风险。
怎么准确的实践接口隔离原则？一句话：实践，经验和领悟！
