细化阶段:迭代2 GRASP高内聚案例分析 同样考虑创建 Payment实例,并与Sale类相关联。 如果按照前述的方案1,那么Pos机将具有“支付”的职 责,并完成 makePayment系统操作的部分职责 如果Pos机负责的职责越来越多且与系统操作有关的某些 或大部分工作,它的任务负荷将不断增加,而成为非内聚 的类。 这种方案对于系统实现来说并非不可取,但是需要从系统 整体职责分配的角度出发,它可能具有低内聚的倾向。 如果采用方案2,则将创建 Payment的职责分配给了sale 类,一定程度上支持了POs机的高内聚。 方案2既支持了Pos机类的高内聚也支持了它的低耦合性 所以它是我们所需要的系统设计
细化阶段：迭代2 GRASP 高内聚 案例分析 ◼ 同样考虑创建Payment实例，并与Sale类相关联。 ◼ 如果按照前述的方案1，那么Pos机将具有“支付”的职 责，并完成makePayment系统操作的部分职责。 ◼ 如果Pos机负责的职责越来越多且与系统操作有关的某些 或大部分工作，它的任务负荷将不断增加，而成为非内聚 的类。 ◼ 这种方案对于系统实现来说并非不可取，但是需要从系统 整体职责分配的角度出发，它可能具有低内聚的倾向。 ◼ 如果采用方案2，则将创建Payment的职责分配给了Sale 类，一定程度上支持了Pos机的高内聚。 ◼ 方案2既支持了Pos机类的高内聚也支持了它的低耦合性， 所以它是我们所需要的系统设计
细化阶段:迭代2 GRASP控制器 问题来源:在系统边界之后( BILayer之后)首先接收和协调系统 操作的第一个对象是什么? 控制器是我们寻找的第一个对象,它负责接收和处理系统操作消息。 解决方案:把接收或者处理系统事件的职责分配给这样一个类 1.它代表整个系统、设备或者子系统,称为外观控制器 2.它代表一个发生系统事件的用例场景,称为用例控制器,通常命名为 <Use CaseName> Controller/Coordinator/Session 在相同的用例场景中使用同一个控制器类处理所有的系统事件; 次会话是与一个角色进行交谈的一个实例。 注意:“ window/vew”等类不参与完成与系统事件相关的任务,它们接 收这些事件后,将其委派给控制器。 通常,UI层不应当包含应用逻辑,为此UI层对象必须把外部系统事 件的请求委派给其他层。如果“其他层”为领域层时,就需要确定 相应的领域对象
细化阶段：迭代2 GRASP 控制器 ◼ 问题来源：在系统边界之后（UI Layer之后）首先接收和协调系统 操作的第一个对象是什么？ ◼ 控制器是我们寻找的第一个对象，它负责接收和处理系统操作消息。 ◼ 解决方案：把接收或者处理系统事件的职责分配给这样一个类： 1. 它代表整个系统、设备或者子系统，称为外观控制器 2. 它代表一个发生系统事件的用例场景，称为用例控制器，通常命名为: ⚫ <UseCaseName>Controller/Coordinator/Session ⚫ 在相同的用例场景中使用同一个控制器类处理所有的系统事件； ⚫ 一次会话是与一个角色进行交谈的一个实例。 ⚫ 注意：“window/view”等类不参与完成与系统事件相关的任务，它们接 收这些事件后，将其委派给控制器。 ⚫ 通常，UI层不应当包含应用逻辑，为此UI层对象必须把外部系统事 件的请求委派给其他层。如果“其他层”为领域层时，就需要确定 相应的领域对象
细化阶段:迭代2 GRASP控制器示例 enteritem(d, quantty) :Register EThe F00 Store 网回区 temD Duanny enteritem(id,quantty):ProcessSaleHandler presses button Amm」 两种选择:外观控制器、 Cashier 用例控制器 action Performed( actionEvent Interface Layer a fRame system event message enterltem(itemID, qty Domain 哪个对象应负责接收这个系统事件? 777 Layer 有时称它为控制器或协调者。它通常不 实现职责,而是将职责委托给其他对象 控制器是从界面层到领域层的外观对象 Figure 16.14 Controller for enterltem?
细化阶段：迭代2 GRASP 控制器 示例 哪个对象应负责接收这个系统事件？ 有时称它为控制器或协调者。它通常不 实现职责，而是将职责委托给其他对象 控制器是从界面层到领域层的外观对象 两种选择：外观控制器、 用例控制器