第12章职责链模式绪论.ppt

第12章 职责链模式 （Chain of Responsibility） 回顾 理解策略模式的本质：分离算法，选择实现 能够正确将策略模式与模板方法模式相结合 利用策略模式设计简单应用程序 目标 理解职责链模式的本质：分离职责，动态组合 能够正确选用职责链模式 利用职责链模式设计简单应用程序 问题 一家软件公司规定申请聚餐费用的管理规定：由申请人先填写申请单，交给领导审批.其流程：项目经理审批(只能审批500元以内)?部门经理审批(可以审批1000元以内)?总经理审批(任意额度) 运行 解决问题 职责链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。 基本思路： 解决问题 运行 注意 在标准的职责链模式中，只要有对象处理了请求，这个请求就到此为止，不再被传递和处理了。 隐式接收，客户端只知道提交请求的第一个对象，并不知道最终接收者是谁，但在一般情况下，总是会有一个对象来处理。(但有可能不被处理) 处理多种请求 假设在上例中，除了申请聚餐费用外，还可申请预支差旅费，还是同一职责链。虽然流程相同，但是每个处理类需要处理两种请求。 修改职责接口，增加一个抽象业务方法。 通用请求处理方式-1 用一个通用的请求对象来封装请求传递的参数 定义一个通用调用方法，该方法不区分具体业务，所有业务都是这个方法，将上述通用请求对象作为其参数。 通用请求处理方式-2 扩展通用请求对象，把业务数据”聚餐费用”和”预支差旅费”分别封装进去。 通用请求处理方式-3 实现具体职责对象(项目经理为例) 运行 UML类图 功能链 在实际开发中，一个请求在职责链中传递，每个职责对象负责处理请求的某一方面的功能，处理完成后，不是停止，而是继续向下传递请求，当请求通过很多职责对象处理后，功能也就完成了。 代码 代码 运行 职责链模式特点 优点 ①请求者和接收者松散耦合 ②动态组合职责 缺点 ①产生很多细粒度对象(每个职责对象只处理一个方面的功能) ②不一定能被处理 总结 理解职责链模式的本质：分离职责，动态组合 能够正确选用职责链模式 利用职责链模式设计简单应用程序 设计模式 设计模式 问题： 1.聚餐费用申请的处理流程是 可能会变动； 2.各个处理环节的业务处理也 是会变动的 ①定义一个所有处理请求的对象都要继承实现的抽象类/接口； ②动态构建流程步骤，随时可以重新组合新的流程； Client successor：handler Handler handleRequest:void setSuccessor:void handleRequest:void handleRequest:void ConcreteHandler1 ConcreteHandler2 具体职责 具体职责 具体职责 新增加业务处理方法 这种方式带来问题只要增加一个 新业务，就需要修改职责接口，这是很不灵活的。 聚餐费用 预支差旅费 我们可以扩展其子类来实现新加入 的业务。 这种设计方式通用灵活，有 了新的业务，只需要添加实现 新功能对象就可以。但带来 的缺陷可能会造成对象层次过多。 示例：我们对销售数据按照以下基本顺序进行： 1.权限检查 2.通用数据检查 3.数据逻辑校验 4.真正业务处理 * *