設計模式六大原則（4）：接口隔離原則
加入技術(shù)交流群
問(wèn)題由來(lái)：類(lèi)A通過(guò)接口I依賴(lài)類(lèi)B，類(lèi)C通過(guò)接口I依賴(lài)類(lèi)D，如果接口I對于類(lèi)A和類(lèi)B來(lái)說(shuō)不是最小接口，則類(lèi)B和類(lèi)D必須去實(shí)現他們不需要的方法。
本文引用地址：http://dyxdggzs.com/article/201612/329162.htm解決方案：將臃腫的接口I拆分為獨立的幾個(gè)接口，類(lèi)A和類(lèi)C分別與他們需要的接口建立依賴(lài)關(guān)系。也就是采用接口隔離原則。
舉例來(lái)說(shuō)明接口隔離原則：
（圖1 未遵循接口隔離原則的設計）
這個(gè)圖的意思是：類(lèi)A依賴(lài)接口I中的方法1、方法2、方法3，類(lèi)B是對類(lèi)A依賴(lài)的實(shí)現。類(lèi)C依賴(lài)接口I中的方法1、方法4、方法5，類(lèi)D是對類(lèi)C依賴(lài)的實(shí)現。對于類(lèi)B和類(lèi)D來(lái)說(shuō)，雖然他們都存在著(zhù)用不到的方法（也就是圖中紅色字體標記的方法），但由于實(shí)現了接口I，所以也必須要實(shí)現這些用不到的方法。對類(lèi)圖不熟悉的可以參照程序代碼來(lái)理解，代碼如下：
interface I {
public void method1();
public void method2();
public void method3();
public void method4();
public void method5();
}
class A{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method2();
}
public void depend3(I i){
i.method3();
}
}
class B implements I{
public void method1() {
System.out.println("類(lèi)B實(shí)現接口I的方法1");
}
public void method2() {
System.out.println("類(lèi)B實(shí)現接口I的方法2");
}
public void method3() {
System.out.println("類(lèi)B實(shí)現接口I的方法3");
}
//對于類(lèi)B來(lái)說(shuō)，method4和method5不是必需的，但是由于接口A(yíng)中有這兩個(gè)方法，
//所以在實(shí)現過(guò)程中即使這兩個(gè)方法的方法體為空，也要將這兩個(gè)沒(méi)有作用的方法進(jìn)行實(shí)現。
public void method4() {}
public void method5() {}
}
class C{
public void depend1(I i){
i.method1();
}
public void depend2(I i){
i.method4();
}
public void depend3(I i){
i.method5();
}
}
class D implements I{
public void method1() {
System.out.println("類(lèi)D實(shí)現接口I的方法1");
}
//對于類(lèi)D來(lái)說(shuō)，method2和method3不是必需的，但是由于接口A(yíng)中有這兩個(gè)方法，
//所以在實(shí)現過(guò)程中即使這兩個(gè)方法的方法體為空，也要將這兩個(gè)沒(méi)有作用的方法進(jìn)行實(shí)現。
public void method2() {}
public void method3() {}
public void method4() {
System.out.println("類(lèi)D實(shí)現接口I的方法4");
}
public void method5() {
System.out.println("類(lèi)D實(shí)現接口I的方法5");
}
}
public class Client{
public static void main(String[] args){
A a = new A();
a.depend1(new B());
a.depend2(new B());
a.depend3(new B());
C c = new C();
c.depend1(new D());
c.depend2(new D());
c.depend3(new D());
}
}
可以看到，如果接口過(guò)于臃腫，只要接口中出現的方法，不管對依賴(lài)于它的類(lèi)有沒(méi)有用處，實(shí)現類(lèi)中都必須去實(shí)現這些方法，這顯然不是好的設計。如果將這個(gè)設計修改為符合接口隔離原則，就必須對接口I進(jìn)行拆分。在這里我們將原有的接口I拆分為三個(gè)接口，拆分后的設計如圖2所示：
（圖2 遵循接口隔離原則的設計）
照例貼出程序的代碼，供不熟悉類(lèi)圖的朋友參考：
interface I1 {
public void method1();
}
interface I2 {
public void method2();
public void method3();
}
interface I3 {
public void method4();
public void method5();
}
class A{
public void depend1(I1 i){
i.method1();
}
public void depend2(I2 i){
i.method2();
}
public void depend3(I2 i){
i.method3();
}
}
class B implements I1, I2{
public void method1() {
System.out.println("類(lèi)B實(shí)現接口I1的方法1");
}
public void method2() {
System.out.println("類(lèi)B實(shí)現接口I2的方法2");
}
public void method3() {
System.out.println("類(lèi)B實(shí)現接口I2的方法3");
}
}
class C{
public void depend1(I1 i){
i.method1();
}
public void depend2(I3 i){
i.method4();
}
public void depend3(I3 i){
i.method5();
}
}
class D implements I1, I3{
public void method1() {
System.out.println("類(lèi)D實(shí)現接口I1的方法1");
}
public void method4() {
System.out.println("類(lèi)D實(shí)現接口I3的方法4");
}
public void method5() {
System.out.println("類(lèi)D實(shí)現接口I3的方法5");
}
}
接口隔離原則的含義是：建立單一接口，不要建立龐大臃腫的接口，盡量細化接口，接口中的方法盡量少。也就是說(shuō)，我們要為各個(gè)類(lèi)建立專(zhuān)用的接口，而不要試圖去建立一個(gè)很龐大的接口供所有依賴(lài)它的類(lèi)去調用。本文例子中，將一個(gè)龐大的接口變更為3個(gè)專(zhuān)用的接口所采用的就是接口隔離原則。在程序設計中，依賴(lài)幾個(gè)專(zhuān)用的接口要比依賴(lài)一個(gè)綜合的接口更靈活。接口是設計時(shí)對外部設定的“契約”，通過(guò)分散定義多個(gè)接口，可以預防外來(lái)變更的擴散，提高系統的靈活性和可維護性。
說(shuō)到這里，很多人會(huì )覺(jué)的接口隔離原則跟之前的單一職責原則很相似，其實(shí)不然。其一，單一職責原則原注重的是職責；而接口隔離原則注重對接口依賴(lài)的隔離。其二，單一職責原則主要是約束類(lèi)，其次才是接口和方法，它針對的是程序中的實(shí)現和細節；而接口隔離原則主要約束接口接口，主要針對抽象，針對程序整體框架的構建。
采用接口隔離原則對接口進(jìn)行約束時(shí)，要注意以下幾點(diǎn)：
* 接口盡量小，但是要有限度。對接口進(jìn)行細化可以提高程序設計靈活性是不掙的事實(shí)，但是如果過(guò)小，則會(huì )造成接口數量過(guò)多，使設計復雜化。所以一定要適度。
* 為依賴(lài)接口的類(lèi)定制服務(wù)，只暴露給調用的類(lèi)它需要的方法，它不需要的方法則隱藏起來(lái)。只有專(zhuān)注地為一個(gè)模塊提供定制服務(wù)，才能建立最小的依賴(lài)關(guān)系。
* 提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。
運用接口隔離原則，一定要適度，接口設計的過(guò)大或過(guò)小都不好。設計接口的時(shí)候，只有多花些時(shí)間去思考和籌劃，才能準確地實(shí)踐這一原則。
評論