敏捷开发_接口隔离原则
定义
接口隔离原则(Interface Segregation Principle, ISP)，定义为：
1. Clients should not be forced to depend upon interfaces thatthey don’t use. （客户端不应该依赖它不需要的接口。）
2. The dependency of one class to another one should depend onthe smallest possible interface. （类间的依赖关系应该建立在最小的接口上。）
接口隔离原则是对接口的使用进行约束规范的一个原则，它告诉我们要想把接口用好，关键在于隔离。隔离，指断绝接触、断绝往来。那么我们使用接口时，要隔离什么东西呢？对于上述定义的第1点，“客户端不应该依赖它不需要的接口”，这里的隔离是指客户端和它不需要的接口隔离，也就是客户端不要使用它不需要的接口，这个很容易理解，在实践中也很容易实现。我们着重看一下第2点，“类间的依赖关系应该建立在最小的接口上”，它要求“最小的接口”，也就是该接口中没有多余的方法，所以这里的隔离是指和多余的方法隔离。
综上所述，接口隔离原则告诉我们，不要把一大堆方法塞进一个接口里，导致这个接口变得臃肿无比。应该要根据实际需要，让接口中只有用得上的方法，直接点就是细粒度接口搭建大的功能。
好处
接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。
1. 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
2. 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
3. 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
4. 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
5. 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。
接口隔离原则的实现方法
在具体应用接口隔离原则时，应该根据以下几个规则来衡量。
· 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
· 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
· 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
· 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
实例
类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类C来说不是最小接口，而类B和类D必须去实现它们不需要的方法。下面通过一个UML图来说明这种现象：
在这里，我们定义了一个动物活动的接口IAnimal，里面有4个方法：
飞行fly、行走walk、吃eat和工作work；
然后分别用人类People和鸟类Bird实现了这个接口。中国人类ChinesePeople和鹦鹉类Parrot通过接口IAnimal分别依赖类People和类Bird。很明显，对于ChinesePeople来说，fly方法是多余的，因为人不会飞；对于Parrot类来说，work方法是多余的，因为鹦鹉不需要工作。接口IAnimal对于类ChinesePeople和类Parrot来说不是最小接口。
将臃肿的接口IAnimal拆分为独立的几个接口，类ChinesePeople和类Parrot分别与它们需要的接口建立依赖关系，也就是采用接口隔离原则。修改后的UML图如下所示：
class IAnimal
{
virtural void walk()=0;
virtural void eat()=0;
}
class IPeople
{
virtural void work()=0;
}
class IBird
{
virtural void fly()=0;
}
class People: publicIAnimal, public IPeople
{
void walk()
{
print("People walk");
}
void eat()
{
print("People eat");
}
void work()
{
print("People work");
}
}
class Bird: publicIAnimal,public IBird
{
void eat()
{
print("Bird eat");
}
void fly()
{
print("Bird Fly");
}
}
class ChinesePeople
{
People* chinesePeople;
void peopleWalk()
{
chinesePeople->walk();
}
void peopleEat()
{
chinesePeople->eat();
}
void peopleWork()
{
chinesePeople->work();
}
}
class Parrot
{
Bird* parrot;
void parrotEat()
{
parrot->eat();
}
void parrotFly()
{
parrot->fly();
}
}
ChinesePeople*chinesePeople = new ChinesePeople();
chinesePeople->chinesePeople= new People();
chinesePeople->peopleEat(); //打印：People eat
Parrot* parrot =Parrot();
parrot->parrot = newBird();
parrot->parrotEat(); //打印：Bird eat
注意
接口隔离原则和单一职责原则类似。单一职责原则要求接口的职责是单一的，而接口隔离原则要求接口尽量细化，都是要让我们的接口功能尽量单一，尽量细小。
不过，两者的侧重点不同，单一职责原则的着重点是在“职责”，而接口隔离原则只单纯地要求接口最小化。那么，如果已经满足单一职责原则的接口，在当前的需求下还可以继续细化，那么还需要细化吗？答案是不要再细化了。在实践中，接口设计的粒度越小，系统就越灵活，但是灵活的同时也带来了系统的复杂化，导致开发维护难度增加。所以接口并不是越小越好，必须要有一个度。当单一职责原则和接口隔离原则存在矛盾时，以满足单一职责原则为底线。