设计模式六大原则之接口隔离原则

本文参考《设计模式之禅》一书

接口隔离原则定义:建立单一接口,不要建立臃肿庞大的接口。

   通俗一点讲:接口尽量细化,同时接口中的方法尽量少。


在讲接口隔离原则之前,先明确一下我们的主角——接口。

接口分为两种:

● 实例接口(Object Interface)

          在Java中声明一个类,然后用new关键字产生一个实例,它是对一个类型的事物的描述,这是一种接口。比如你定义Person这个类,然后使用Person zhangSan=new Person()产生了一个实例,这个实例要遵从的标准就是Person这个类,Person类就是zhangSan的接口。疑惑?看不懂?不要紧,那是因为让Java语言浸染的时间太长了,只要知道从这个角度来看,Java中的类也是一种接口。

● 类接口(Class Interface)

          Java中经常使用的interface关键字定义的接口。

主角已经定义清楚了,那什么是隔离呢?

它有两种定义,如下所示:

● 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.(类间的依赖关系应该建立在最小的接口上。)

新事物的定义一般都比较难理解,晦涩难懂是正常的。我们把这两个定义剖析一下,先说第一种定义:“客户端不应该依赖它不需要的接口”,那依赖什么?依赖它需要的接口,客户端需要什么接口就提供什么接口,把不需要的接口剔除掉,那就需要对接口进行细化,保证其纯洁性;

再看第二种定义:“类间的依赖关系应该建立在最小的接口上”,它要求是最小的接口,也是要求接口细化,接口纯洁,与第一个定义如出一辙,只是一个事物的两种不同描述。


保证接口的纯洁性(接口隔离原则是对接口进行规范约束)

● 接口要尽量小

这是接口隔离原则的核心定义,不出现臃肿的接口(Fat Interface), 如何做到?根据接口隔离原则拆分接口时,首先必须满足单一职责原则。

● 接口要高内聚

什么是高内聚?高内聚就是提高接口、类、模块的处理能力,减少对外的交互。   要求在接口中尽量少公布public方法,接口是对外的承诺,承诺越少对系统的开发越有利,变更的风险也就越少,同时也有利于降低成本。

● 定制服务

什么是定制服务?定制服务就是单独为一个个体提供优良的服务。我们在做系统设计时也需要考虑对系统之间

或模块之间的接口采用定制服务。采用定制服务就必然有一个要求:只提供访问者需要的方法。

● 接口设计是有限度的

接口的设计粒度越小,系统越灵活,这是不争的事实。但是,灵活的同时也带来了结构的复杂化,开发难度

加,可维护性降低,这不是一个项目或产品所期望看到的,所以接口设计一定要注意适度,这个“度”如何来判断呢?

根据经验和常识判断,没有一个固化或可测量的标准。


接口隔离和单一职责不是一回事:

这与单一职责原则不是相同的吗?错,接口隔离原则与单一职责的审视角度是不相同的,单一职责要求的是类和接口职责单一,注重的是职责,这是业务逻辑上的划分,而接口隔离原则要求接口的方法尽量少。

例如一个接口的职责可能包含10个方法,这10个方法都放在一个接口中,并且提供给多个模块访问,各个模块按照规定的权限来访问,在系统外通过文档约束“不使用的方法不要访问”,按照单一职责原则是允许的,按照接口隔离原则是不允许的,因为它要求“尽量使用多个专门的接口”。专门的接口指什么?就是指提供给每个模块的都应该是单一接口,提供给几个模块就应该有几个接口,而不是建立一个庞大的臃肿的接口,容纳所有的客户端访问。


最佳实践

接口隔离原则是对接口的定义,同时也是对类的定义,接口和类尽量使用原子接口或原子类来组装。但是,这个原子该怎么划分是设计模式中的一大难题,在实践中可以根据以下几个规则来衡量:

● 一个接口只服务于一个子模块或业务逻辑;

● 通过业务逻辑压缩接口中的public方法,接口时常去回顾,尽量让接口达到“满身筋骨肉”,而不是“肥嘟嘟”的一大堆方法;

● 已经被污染了的接口,尽量去修改,若变更的风险较大,则采用适配器模式进行转化处理;

● 了解环境,拒绝盲从。每个项目或产品都有特定的环境因素,别看到大师是这样做的你就照抄。千万别,环境不同,接口拆分的标准就不同。深入了解业务逻辑,最好的接口设计就出自你的手中!


那怎么才能正确地使用接口隔离原则呢?

答案是根据经验和常识决定接口的粒度大小,接口粒度太小,导致接口数据剧增,开发人员呛死在接口的海洋里;接口粒度太大,灵活性降低,无法提供定制服务,给整体项目带来无法预料的风险。

你可能感兴趣的:(--设计模式之禅,--)