pp看书笔记---设计模式之禅第二版 第四章【接口隔离原则】

定义

1.客户端不应该依赖它不需要的接口
2.类之间的依赖关系应该建立在最小的接口上


作者阐释的4种含义

1.接口要尽量小
2.接口要高内聚
3.定制服务
4.接口设计是有限度的


我对作者4层含义的解析

1.作者举了一个很好的例子,电话的设计,接电话、挂断电话都属于通信连接,设置成一个接口,如果细究接口要尽量小这一点,你会说挂断有异常挂断、人为挂断,那是不是还要设计挂断的接口,然后分别实现?作者非常不赞成,如果这么细,别指望设计下去了。

我现在的实践中IWrite接口负责将XX入库,但是根据XX的编号来查询入库:

  • 如果XX编号:入库
  • 如果有XX编号,其他属性与库中属性不同:修改
  • 如果有XX编号,其他属性与库中属性一致:不用入库
    我的IWrite接口也是如此,仅有写入,但是具体是写入呢、修改呢、不需要写入呢都是实现类中Private的事了
    这里作者这样设计、我这样设计的原因都一样,是最小业务单元(挂断就是挂断,管你怎么挂断;入库就是入库,管你是写入还是修改还是不需要再次写入;我是接口唉,我只负责抽象的事情,那么细节的事我不关心)
    pp看书笔记---设计模式之禅第二版 第四章【接口隔离原则】_第1张图片

2.作者举了一个很好的例子,老板吩咐员工做一件事,一个月后员工将做好的结果放在老板桌子上,这也很好理解,还和我IWrite的例子一样,我只负责你入库,你里面做了很多事,互相牵扯内聚高我不关心,我仅看结果pp看书笔记---设计模式之禅第二版 第四章【接口隔离原则】_第2张图片

3.这一点我的程序中没有用到,不过也很好理解,即使功能相近业务相近,但谁需要给谁,不要为了方便放在一起写,作者也举了很恰当的例子,有按书名、作者查询等多种方法,不同权限的查询不同,那就分别为它们定义查询的接口,别写在一起

4.应该是作者的感慨,和我上一篇文章中说的审时度势是一个意思,粒度问题,粒度小在设计角度上来说灵活,但实现角度会复杂


我学到的东西

1.让我从另外一个角度明白类也是一个接口,接口不仅指虚类、Interface,类也是一种接口,一个Person类,不就是一个抽象的接口吗?只不过你实例为张三、李四而已

2.作者在开篇时定义接口隔离原则时提到客户端,我联想这样的CS程序,我们尽量做到Main程序不便,外接工程、接口……可以更换实现,这不就是用户打开网站,今天是端午节,有端午节的Logo,明天是七夕,窗口上有牛郎一样,都是在搜索栏上方加一个图片,功能不变、业务基调不变,仅仅是变了图片

你可能感兴趣的:(废弃)