OOD之接口隔离原则

[u][i]这个系列是早前发布在部门wiki上的，引导组里的兄弟入门OOD，希望同样对刚刚走到OOD门前的同学有用。[/i][/u]

现实中的每个人都要承担各式各样的职责，这些职责通常是由他面对的"客户"所决定的，比如一个部门经理，面对老板他的职责是执行、汇报工作等，面对部门员工他的职责是分派任务，监控执行等，面对客户他的职责是了解需求、解答疑问等；如果回到家，面对老人他的职责是尽孝道，面对孩子他的职责是抚养教育。。。这些职责取决于面对的"客户"，对这个"客户"的职责不能用在那个"客户"身上，不能乱，一乱就坏了。
同样，软件世界中的对象也应该是这样的，如果它要面对多个客户，需要为每个客户提供该客户关心的职责，"[b]不应该强迫客户依赖于它们不用的方法[/b]"。这就是所谓的接口隔离原则（ISP）。
我们系统中需要使用接口隔离原则的地方不多，因为大部分类只有一个客户。值得一提的是消息监听类的实现，比如补单模块的补单监听器类，这个类的设计如下：

[img]http://dl.iteye.com/upload/attachment/151250/009f3869-d903-38a3-b51d-daae8c74a3ab.jpg[/img]

这个ReissueListener在AppRequestHandler之外，又实现了一个ReissueService接口，为什么要这样做而不是直接把补单逻辑放到AppRequestHandler的handleAppRequest方法中呢（事实上我们有好多监听器类是直接把业务逻辑实现在这个方法中了）？
我们可以这样来看这个问题：补单这个地方使用了MQ，MQ只是一个纯技术上的实现方式，没有业务上的意义，从业务角度讲，补单完成后，负责补单的程序需要调用补单成功的逻辑，这里"负责补单的程序"是ReissueListener的一个客户，我们要为它提供一个调用接口，定名为ReissueListener。但是因为架构解耦和性能方面的考虑，补单程序需要从MQ接收补单成功的消息而不是直接被"负责补单的程序"调用了，针对MQ这个新客户，架构的基础设施里面规定了一个AppRequestHandler接口，所有监听消息的实现都需要实现它。
为消息监听器类保留有业务意义的接口总是有意义的，不仅保存了监听器类的业务意义，而且使它更便于单元测试。
遵循ISP的关键是明确软件类的客户和它们的需求，然后分别予以抽象。