一. 接口隔离原则的定义
Clients should not be forced to depend upon interfaces that they don't use.
客户端只依赖于它所需要的接口;它需要什么接口就提供什么接口,把不需要的接口剔除掉。
The dependency of one class to another one should depend on the smallest possible interface.
类间的依赖关系应建立在最小的接口上。
也就是说: 接口尽量细化,接口中的方法尽量少
二. 接口隔离原则和单一职责原则
从功能上来看,接口隔离原则和单一职责原则都是为了提高类的内聚, 降低类之间的耦合, 体现了封装的思想。但二者还是有区别的。
(1)从原则约束来看: 接口隔离原则更关注的是接口依赖程度的隔离;而单一职责原则更加注重的是接口职责的划分。
(2)从接口的细化程度来看: 单一职责原则对接口的划分更加精细,而接口隔离原则注重的是相同功能的接口的隔离。接口隔离里面的最小接口有时可以是多个单一职责的公共接口。
(3)单一职责原则更加偏向对业务的约束: 接口隔离原则更加偏向设计架构的约束。这个应该好理解,职责是根据业务功能来划分的,所以单一原则更加偏向业务;而接口隔离更多是为了“高内聚”,偏向架构的设计。
三. 接口隔离原则的优点
接口隔离原则是为了约束接口、降低类对接口的依赖性,遵循接口隔离原则有以下 5 个优点。
- 将臃肿庞大的接口分解为多个粒度小的接口,可以预防外来变更的扩散,提高系统的灵活性和可维护性。
- 接口隔离提高了系统的内聚性,减少了对外交互,降低了系统的耦合性。
- 如果接口的粒度大小定义合理,能够保证系统的稳定性;然而,如果定义过小,则会造成接口数量过多,使设计复杂化;如果定义太大,灵活性降低,无法提供定制服务,给整体项目带来无法预料的风险。
- 使用多个专门的接口能够体现对象的层次,因为可以通过接口的继承,实现对总接口的定义。
- 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法,当实现这个接口的时候,被迫设计冗余的代码。
四. 接口隔离原则的实现方法
在具体应用接口隔离原则时,应该根据以下几个规则来衡量。
1)接口要尽量小
不能出现Fat Interface;但是要有限度,首先不能违反单一职责原则(不能一个接口对应半个职责)。
2)接口要高内聚
在接口中尽量少公布public方法。
接口是对外的承诺,承诺越少对系统的开发越有利。
3)定制服务
只提供访问者需要的方法。例如,为管理员提供IComplexSearcher接口,为公网提供ISimpleSearcher接口。
4)接口的设计是有限度的
了解环境,拒绝盲从。每个项目或产品都有选定的环境因素,环境不同,接口拆分的标准就不同, 需要深入了解业务逻辑。
五. 接口隔离原则的建议
- 一个接口只服务于一个子模块或业务逻辑;
- 通过业务逻辑压缩接口中的public方法;
- 已被污染了的接口,尽量去修改;若变更的风险较大,则采用适配器模式转化处理;
- 拒绝盲从
五. 案例分析
下面以学生成绩管理为例来说明接口隔离原则:
分析:学生成绩管理程序一般包含查询成绩、新增成绩、删除成绩、修改成绩、计算总分、计算平均分、打印成绩信息等功能,通常我们会怎么做呢?
一: 最初的设计
通常我们设计接口的方式如下:
public interface IStudentScore { // 查询成绩 public void queryScore(); // 修改成绩 public void updateScore(); // 添加成绩 public void saveScore(); // 删除成绩 public void delete(); // 计算总分 public double sum(); // 计算平均分 public double avg(); // 打印成绩单 public void printScore(); }
我们会吧所有的功能都放在一个接口里面. 这会产生什么样的问题呢?
首先, 接口的方法很多, 不利于扩展. 比如: 学生只有查看成绩,打印成绩单的权限, 没有增删改的权限; 老师拥有所有的权限.
查询成绩单:
package com.lxl.www.designPatterns.sixPrinciple.interfaceSegregationPrinciple.score; public class QueryScore implements IStudentScore{ @Override public void queryScore() { // 查询成绩 } @Override public void updateScore() { // 没有权限 } @Override public void saveScore() { // 没有权限 } @Override public void delete() { // 没有权限 } @Override public double sum() { // 没有权限 return 0; } @Override public double avg() { // 没有权限 return 0; } @Override public void printScore() { //打印成绩单 } }
操作成绩单
package com.lxl.www.designPatterns.sixPrinciple.interfaceSegregationPrinciple.score; public class Operate implements IStudentScore{ @Override public void queryScore() { } @Override public void updateScore() { } @Override public void saveScore() { } @Override public void delete() { } @Override public double sum() { return 0; } @Override public double avg() { return 0; } @Override public void printScore() { } }
可以看出问题. 查询成绩单, 我们只会用到两个方法, 可是因为实现了接口, 不得不重写所有的方法.
如果这时候增加需求--发送给家长, 只有老师才有这个权限, 学生没有这个权限. 可是, 在接口中增加一个抽象方法以后, 所有的实现类都要重写这个方法. 这就违背了开闭原则.
2. 使用接口隔离原则的设计
采用接口隔离原则设计的接口, UML图如下:
public interface IQueryScore { // 查询成绩 public void queryScore(); // 打印成绩单 public void printScore(); } public interface IOperateScore { // 修改成绩 public void updateScore(); // 添加成绩 public void saveScore(); // 删除成绩 public void delete(); // 计算总分 public double sum(); // 计算平均分 public double avg(); } public class StudentOperate implements IQueryScore{ @Override public void queryScore() { // 查询成绩 } @Override public void printScore() { //打印成绩单 } } public class TeacherOperate implements IQueryScore, IOperateScore{ @Override public void queryScore() { } @Override public void updateScore() { } @Override public void saveScore() { } @Override public void delete() { } @Override public double sum() { return 0; } @Override public double avg() { return 0; } @Override public void printScore() { } }
我们将原来的一个接口进行了接口拆分. 分为查询接口和操作接口. 这样学生端就不需要重写和他不相关的接口了.
如果将这些功能全部放到一个接口中显然不太合理,正确的做法是将它们分别放在输入模块、统计模块和打印模块等 3 个模块中,其类图如图 1 所示
全部评论
(2) 回帖