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

接口隔离原则
一:什么是接口?
● 实例接口(Object Interface)
        ---->Person zhangSan=new Person()产生了一个实例,这个实例要遵从的标准就是Person这个类,Person类就是zhangSan的接口
● 类接口(Class Interface)
        ---->Java中经常使用的interface关键字定义的接口。

二:那什么是隔离呢?它有两种定义:
      ---->事物的定义一般都比较难理解,晦涩难懂是正常的。我们把这两个定义剖析一下
         ---->第一种定义:客户端不应该依赖它不需要的接口”,那依赖什么?依赖它需要的接口,客户端需要什么接口就提供什么接口,把不需要的接口剔除掉,那就需要对接口进行细化,保证其纯洁性.
         ---->第二种定义:类间的依赖关系应该建立在最小的接口上”,它要求是最小的接口,也是要求接口细化,接口纯洁,与第一个定义如出一辙,只是一个事物的两种不同描述。
         ---->总结:建立单一接口,不要建立臃肿庞大的接口。再通俗一点讲:接口尽量细化,同时接口中的方法尽量少
         ---->疑惑点:看到这里大家有可能要疑惑了,这与单一职责原则不是相同的吗?错,接口隔离原则与单一职责的审视角度是不相同的,单一职责要求的是类和接口职责单一,注重的是职责,这是业务逻辑上的划分,而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法,这10个方法都放在一个接口中,并且提供给多个模块访问,各个模块按照规定的权限来访问,在系统外通过文档约束“不使用的方法不要访问”,按照单一职责原则是允许的,按照接口隔离原则是不允许的,因为它要求“尽量使用多个专门的口”。专门的接口指什么?就是指提供给每个模块的都应该是单一接口,提供给几个模块就应该有几个接口,而不是建立一个庞大的臃肿的接口,容纳所有的客户端访问。
        
        例子:
        美女分为脸蛋气质美女和身材美女
        一个脸蛋气质的接口
        一个身材美女的接口
        一个抽象类拥有两个接口的依赖

一个脸蛋气质的接口
package com.yeepay.sxf.sjms1;
/**
 * 五官气质美女接口
 * @author sxf
 *
 */
public interface IGoodBodyGirl {
        /**
         * 好看的五官外貌
         */
        public void goodLooking();
        /**
         * 有气质
         */
        public void greatTemperament();
        
}

  一个身材美女的接口
package com.yeepay.sxf.sjms1;
/**
 * 身材美女
 * @author sxf
 *
 */
public interface IGreatTemperamentGirl{

        /**
         * 好身材
         */
        public void niceFigure();
}

  一个抽象类拥有两个接口的依赖
package com.yeepay.sxf.sjms1;
/**
 * 星探的抽象类
 * @author sxf
 *
 */
public abstract class AbstractSearcher2 {
        /**
         * 脸蛋气质美女
         */
        protected IGoodBodyGirl iGoodBodyGirl;
        /**
         * 脸蛋气质身材美女
         */
        protected IGreatTemperamentGirl iGreatTemperamentGirl;
        /**
         * 脸蛋气质美女
         * @param pettyGirl
         */
        public AbstractSearcher2(IGoodBodyGirl iGoodBodyGirl){
                this.iGoodBodyGirl=iGoodBodyGirl;
        }
        /**
         * 脸蛋气质身材美女
         * @param iGreatTemperamentGirl
         */
        public AbstractSearcher2(IGreatTemperamentGirl iGreatTemperamentGirl){
                this.iGreatTemperamentGirl=iGreatTemperamentGirl;
        }
        /**
         * 搜索美女
         */
        public abstract void show();
}
三:如何保证接口的纯洁性
● 接口要尽量小
        --->这是接口隔离原则的核心定义,不出现臃肿的接口(Fat Interface),但是“小”是有限度的,首先就是不能违反单一职责原则
        --->根据接口隔离原则拆分接口时,首先必须满足单一职责原则

● 接口要高内聚
        --->什么是高内聚?高内聚就是提高接口、类、模块的处理能力,减少对外的交互。比如你告诉下属“到奥巴马的办公室偷一个×××文件”,然后听到下属用坚定的口吻回答你:“是,保证完成任务!”一个月后,你的下属还真的把×××文件放到你的办公桌上了,这种不讲任何条件、立刻完成任务的行为就是高内聚的表现。具体到接口隔离原则就是,要求在接口中尽量少公布public方法,接口是对外的承诺,承诺越少对系统的开发越有利,变更的风险也就越少,同时也有利于降低成本。

● 定制服务
        --->一个系统或系统内的模块之间必然会有耦合,有耦合就要有相互访问的接口(并不一定就是Java中定义的Interface,也可能是一个类或单纯的数据交换),我们设计时就需要为各个访问者(即客户端)定制服务,什么是定制服务?定制服务就是单独为一个个体提供优良的服务。我们在做系统设计时也需要考虑对系统之间或模块之间的接口采用定制服务。采用定制服务就必然有一个要求:只提供访问者需要的方法

● 接口设计是有限度的
        --->接口的设计粒度越小,系统越灵活,这是不争的事实。但是,灵活的同时也带来了结构的复杂化,开发难度增加,可维护性降低,这不是一个项目或产品所期望看到的,所以接口设计一定要注意适度

四:最佳实践
        接口隔离原则是对接口的定义,同时也是对类的定义,接口和类尽量使用原子接口或原子类来组装。但是,这个原子该怎么划分是设计模式中的一大难题,在实践中可以根据以下几个规则来衡量:
        ● 一个接口只服务于一个子模块或业务逻辑;
        ● 通过业务逻辑压缩接口中的public方法,接口时常去回顾,尽量让接口达到“满身筋骨肉”,而不是“肥嘟嘟”的一大堆方法;
        ● 已经被污染了的接口,尽量去修改,若变更的风险较大,则采用适配器模式进行转化处理;
        ● 了解环境,拒绝盲从。每个项目或产品都有特定的环境因素,别看到大师是这样做的你就照抄。千万别,环境不同,接口拆分的标准就不同。深入了解业务逻辑,最好的接口设计就出自你的手中!

时间: 2024-08-01 12:10:08

设计模式之禅之六大设计原则-接口隔离原则的相关文章

设计模式之禅之六大设计原则-开闭原则

开闭原则 一:开闭原则的定义        --->一个软件实体如类.模块和函数应该对扩展开放,对修改关闭.        --->我们做一件事情,或者选择一个方向,一般需要经历三个步骤:What--是什么,Why--为什么,How--怎么做(简称3W原则,How取最后一个w)        --->对于开闭原则,我们也采用这三步来分析,即什么是开闭原则,为什么要使用开闭原则,怎么使用开闭原则? 二:如何使用开闭原则        --->抽象约束.               

设计模式之禅之六大设计原则-依赖倒置原则

依赖倒置原则依赖倒置原则的原始定义是:● 高层模块不应该依赖低层模块,两者都应该依赖其抽象;● 抽象不应该依赖细节;● 细节应该依赖抽象. 那什么是抽象?什么又是细节呢?---->在Java语言中,抽象就是指接口或抽象类,两者都是不能直接被实例化的;细节就是实现类,实现接口或继承抽象类而产生的类就是细节,其特点就是可以直接被实例化,也就是可以加上一个关键字new产生一个对象.依赖倒置原则在Java语言中的表现就是: ● 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接

设计模式之禅之六大设计原则-单一职责原则

单一职责原则--->类从属性维度的划分:名词属性,动作属性.例如.用户类(User),用户行为类.(UserService)--->类和接口的设计原则要追求的目标是:有且仅有一个原因能引起它的变化.也就是一个接口或类只有一个职责,它就负责同一类的事情,如果所负责的业务超过两类或两类以上,则考虑拆分成不同的接口.   单一职责原则的好处--->类的复杂性降低,实现什么指责都清晰明确的定义--->可读性提高,因为复杂性降低,因此刻度性提高.--->可维护性提高,因为可读性提高,因

设计模式之禅之六大设计原则-迪米特原则

迪米特法则 一:迪米特法则定义:        ---->迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least KnowledgePrinciple,LKP),        ---->一个对象应该对其他对象有最少的了解.通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的这么多public方法,我就调用这么多,其他的我一概不关心. 二:迪米特法则对类的低耦合提出明确的要求.   

设计模式之禅之六大设计原则-里氏替换原则

里氏替换原则说的就是面向对象语言的继承--->代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性.--->提高代码的重用性.--->子类可以形似父类,但又特殊于父类.--->提高代码的可扩展性.实现父类的方法,可以为所欲为.许多开源框架的接口都是继承父类完成的.--->提高产品或项目的开放性.--->继承是侵入性的.子类必须拥有父类的属性和方法.让子类自由的世界中多了些约束.--->增强了耦合性.当父类的常量,变量和方法被修改时,需要考虑子类的修改.造成

举例说明Java设计模式编程中ISP接口隔离原则的使用_java

Interface Segregation Principle,ISP接口隔离原则主张使用多个专门的接口比使用单一的总接口要好. 一个类对另外一个类的依赖性应当是建立在最小的接口上的. 一个接口代表一个角色,不应当将不同的角色都交给一个接口.没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染. "不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构."这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法

《Android 源码设计模式解析与实战》——第1章,第1.5节系统有更高的灵活性——接口隔离原则

1.5 系统有更高的灵活性--接口隔离原则 接口隔离原则英文全称是InterfaceSegregation Principles,缩写是ISP.ISP的定义是:客户端不应该依赖它不需要的接口.另一种定义是:类间的依赖关系应该建立在最小的接口上.接口隔离原则将非常庞大.臃肿的接口拆分成更小的和更具体的接口,这样客户将会只需要知道他们感兴趣的方法.接口隔离原则的目的是系统解开耦合,从而容易重构.更改和重新部署. 接口隔离原则说白了就是,让客户端依赖的接口尽可能地小,这样说可能还是有点抽象,我们还是以

设计模式六大原则(4):接口隔离原则

定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: (图1  未遵循接口隔离原则的设计)          这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖

简单理解遵循接口隔离原则的Java设计模式编程_java

定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则:  这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现.类C依赖接口I中的方法1.方法4.方法5,类D