六大设计原则详解(4)-接口隔离原则
接口隔离原则(Interface Segregation Principle ),客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。
从定义上总结起来,要建立单一的接口,并且接口里的方法越少越好,这里说的接口指的是类接口,也就是Interface关键字定义的接口。
接口隔离原则和单一职责原则的区别:
单一职责原则指的是类、接口和方法的职责是单一的,强调的是职责,也就是说在一个接口里,只要职责是单一的,有10个方法也是可以的。
接口隔离原则指的是在接口中的方法尽量越来越少,接口隔离原则的前提必须先符合单一职责,在单一职责的前提下,接口尽量是单一接口。
下面用实例来说明一下
一.接口臃肿实例
1.首先定义一个接口,声明体育课可以玩的球类
public interface PEclass_Ball { public void PlayBasketball(); public void PlayFootball(); public void PlayVolleyball(); }
2.学生去实现(实现类)
public class Students implements PEclass_Ball { @Override public void PlayBasketball() { System.out.println("可以打篮球"); } @Override public void PlayFootball() { System.out.println("可以踢足球"); } @Override public void PlayVolleyball() { System.out.println("可以打排球"); } @Override public void PlayPlaytabletennis() { System.out.println("可以打乒乓球"); } }
场景中声明了体育课可以玩四种球,现在改变一下,体育课只能打篮球,如果还是按照此接口写的话,其他的三个方法都是空的。代码如下:
public class Students implements PEclass_Ball { @Override public void PlayBasketball() { System.out.println("可以打篮球"); } @Override public void PlayFootball() { } @Override public void PlayVolleyball() { } @Override public void PlayPlaytabletennis() { } }
二.拆分接口实例
给实例1增加一个场景,如果我们体育课,男生只踢足球和打篮球,女生打排球和乒乓球,这种情况我们要拆分接口。
public interface ball_1 { public void PlayBasketball(); public void PlayFootball(); }
public interface ball_2 { public void PlayVolleyball(); public void PlayPlaytabletennis(); }
上面两个实例其实都反应的是一个问题,接口不能太过臃肿,根据接口隔离原则,应该建立单一接口。
总结:
(1). 接口要尽量小。
这是接口隔离原则的核心定义,不出现臃肿的接口(Fat Interface),但是“小”是有限度的,首先就是不能违反单一职责原则。
根据接口隔离原则拆分接口时,首先必须满足单一职责原则。
(2). 接口要高内聚。
高内聚就是要提高接口、类、模块的处理能力,减少对外的交互。
具体到接口隔离原则就是,要求在接口中尽量少公布public方法,接口是对外的承诺,承诺地越少对系统开发越有利,变更的风险也就越少,同时也有利于降低成本。
(3). 定制服务。
定制服务就是单独为一个个体提供优良的服务。
(4). 接口设计是有限度的。
接口的设计粒度越小,系统越灵活,这是不争的事实。但是,灵活的同时也带来了结构的复杂化,开发难度增加,可维护性降低,这不是一个项目或产品所期望看到的,所以接口设计一定要注意适度,这个度只能根据经验和常识判断,没有一个固化或可测量的标准。
最后我想说,一本书,我们看得懂不一定能说出来,能说出来不一定能写出来,多写写一定有收获!
推荐阅读