接口隔离ISP
来源:互联网 发布:淘宝联盟怎么省钱 编辑:程序博客网 时间:2024/05/16 12:03
不应该强迫客户依赖于它们不用的方法。
接口隔离可以让用户端仅仅关注行为,而不是实现这种行为的对象。
例如有一个功能:一个闹钟,当定时器超时的时候闹钟会响;
1 class Bell 2 { 3 void Ring() 4 { 5 6 } 7 } 8 9 class Timer10 {11 void onTimeOut(Bell b)12 {13 b.Ring();14 }15 }
这里面两个问题,第一、定时器超时是一个timer类依赖于Bell,这个依赖是不必要的,第二、定时器的超时其实很功能很单一,所以我想要它能够实现其他对象的超时处理,比如说,一个Light超时了会关闭。这样的话我就要增加一个基类,让Bell和Light同时从这个类继承出来。
但是在大多数情况下Light和Bell是完全两个不同的东西,没有理由将他们从同一个类继承。
这时候需要一个接口
1 interface TimeOut2 {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 : TimeOut13 {14 void onTimeOut()15 {16 Close();17 }18 void Close()19 {20 21 }22 }23 class Timer24 {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接口。
- ISP 接口隔离原则
- 接口隔离原则--ISP
- 接口隔离原则--ISP
- 接口隔离原则--ISP
- 接口隔离ISP
- 接口隔离原则--ISP
- ISP接口隔离原则
- ISP接口隔离原则
- 接口隔离原则(ISP)
- 接口隔离原则(ISP)
- ISP简介(ISP--Interface Segregation Principle)接口隔离原则
- 接口隔离ISP--Interface Segregation Principle
- 接口隔离原则--ISP(转)
- ISP 接口隔离原则 Interface Seperate Principle
- 软件设计原则----接口隔离原则(ISP)
- 软件设计原则----接口隔离原则(ISP)
- ISP(Interface Segregation Principle),接口隔离原则
- 第5章 接口隔离原则(ISP)
- C# 扩展方法
- 单一职责
- OCP开放闭合
- 里氏替换
- 依赖倒置DIP
- 接口隔离ISP
- 创建我的第一个开源项目
- 从一个构造函数谈谈的代码的封装性和怎么表现自己的意图
- C/C++零碎知识总结
- 模板方法模式
- C/C++零碎知识整理(二)
- 10. auto_ptr总结
- 9. c++异常说明
- 8. java编程思想读书笔记(一)