一、接口隔离原则
1、原理
客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上。如果强迫客户端依赖于那些它们不使用的接口,那么客户端就面临着这个未使用的接口的改变所带来的变更,这无意间导致了客户程序之间的耦合。换种说法,如果一个客户程序依赖于一个含有它不使用的方法的类,但是其他客户程序确需要使用该方法,那么当其他客户要求这个类改变时,就会影响到这个客户程序。我们希望尽可能地避免这种耦合,因此我们希望分离接口。
2、示例
2.1、迭代一
A类通过接口依赖B类,B类实现接口全部方法,但是A类只使用B类的func1、func2、func3等三个方法;C类通过接口依赖D类,D类实现接口全部方法,C类使用到接口的func1、func4、func5等三个方法。UML类图,如下:
代码如下:
#include <iostream>
using namespace std;
// Interface 接口
class Interface
{
public:
virtual void func1();
virtual void func2();
virtual void func3();
virtual void func4();
virtual void func5();
};
// B 类
class B : public Interface
{
public:
void func1(){
cout << "B 类实现 func1" << endl;
}
void func2(){
cout << "B 类实现 func2" << endl;
}
void func3(){
cout << "B 类实现 func3" << endl;
}
void func4(){
cout << "B 类实现 func4" << endl;
}
void func5(){
cout << "B 类实现 func5" << endl;
}
};
// D 类
class D : public Interface
{
public:
void func1(){
cout << "D 类实现 func1" << endl;
}
void func2(){
cout << "D 类实现 func2" << endl;
}
void func3(){
cout << "D 类实现 func3" << endl;
}
void func4(){
cout << "D 类实现 func4" << endl;
}
void func5(){
cout << "D 类实现 func5" << endl;
}
};
// 1、A类 通过Interface接口 依赖B类
// 2、A类使用到接口的1、2、3等三个方法
class A {
public:
void depend1(Interface &i){
i.func1();
}
void depend2(Interface &i){
i.func2();
}
void depend3(Interface &i){
i.func3();
}
};
// 1、C类 通过Interface接口 依赖D类
// 2、C类使用到接口的1、4、5等三个方法
class C {
public:
void depend1(Interface &i){
i.func1();
}
void depend4(Interface &i){
i.func4();
}
void depend5(Interface &i){
i.func5();
}
};
int main()
{
B objB;
D objD;
A objA;
C objC;
objA.depend1(objB);
objA.depend2(objB);
objA.depend3(objB);
objC.depend1(objD);
objC.depend4(objD);
objC.depend5(objD);
return 0;
}
上面代码存在的问题
- 接口对于类A与类C来说不是最小接口,那么类B和类D必须去实现他们不需要的方法
2.2、迭代二
按照接口分离原则,类A与类C分别于他们需要的接口建立依赖关系,修改后的类图如下:
3、结论
胖类会导致它们的客户程序之间产生不正常的并且有害的耦合关系。当一个客户程序要求该胖类进行一个改动时,会影响到其他的所有的客户程序。因此、客户程序应该仅仅依赖于它们实际调用的方法。通过把胖类的接口分解为多个特定于客户程序的接口,可以实现这个目标。