接口隔离ISP

不应该强迫客户依赖于它们不用的方法。

接口隔离可以让用户端仅仅关注行为，而不是实现这种行为的对象。

例如有一个功能：一个闹钟，当定时器超时的时候闹钟会响；

 1     class Bell

 2     {

 3         void Ring()

 4         {

 5 

 6         }

 7     }

 8 

 9     class Timer

10     {

11         void onTimeOut(Bell b)

12         {

13             b.Ring();

14         }

15     }

这里面两个问题，第一、定时器超时是一个timer类依赖于Bell，这个依赖是不必要的，第二、定时器的超时其实很功能很单一，所以我想要它能够实现其他对象的超时处理，比如说，一个Light超时了会关闭。这样的话我就要增加一个基类，让Bell和Light同时从这个类继承出来。

但是在大多数情况下Light和Bell是完全两个不同的东西，没有理由将他们从同一个类继承。

这时候需要一个接口

1     interface TimeOut

2     {

3         void onTimeOut();

4     }

这个接口用于实现定时器超时处理。

让Bell和Light同时继承这接口

 1     class Bell : TimeOut

 2     {

 3         void onTimeOut()

 4         {

 5             Ring();

 6         }

 7         void Ring()

 8         {

 9 

10         }

11     }

12     class Light : TimeOut

13     {

14         void onTimeOut()

15         {

16             Close();

17         }

18         void Close()

19         {

20 

21         }

22     }

23     class Timer

24     {

25         void onTimeOut(TimeOut t)

26         {

27             t.onTimeOut();

28         }

29     }

这样Timer类就是一个非常通用的类，以后我再添加任何对象，只要从TimeOut继承onTimeOut方法就可以了。

 

接口的使用有的时候会造成接口的臃肿。

有的时候一个类会依赖于不需要的接口。

如果说ATM有存款，取款，转账3部分功能，这三部分功能都会用到UI界面的处理。

为了使得界面和业务处理分开，所有的业务处理都依赖于接口UI，UI的具体实现用UI object来实现。

 

这里面存在一个问题已：UI接口太过于臃肿，因为Despoit会依赖于他们不需要的接口——withdrawal和transfer，其他的两个类也是一样。

解决这种问题的方法是将UI接口拆分掉。

这样Despoit就不会依赖它不需要的接口了。

 

分离接口的原则：按照客户来分离接口，分离客户就是分离接口。比如这里按照三种不同的业务来分离UI接口。