7.4 GRASP原则四：控制器 Controller

4、GRASP原则四：控制器 Controller
　　 What first object beyond the UI layer receives and co-ordinates (controls) a system operation？

　　　　在领域层，由谁负责首先接收并协调来自UI层的系统操作？
4.1 Mini Exercise 4

　　 For Monopoly game, Which object starts the game?
　　 Understanding the Problem

　　　　 SSD — boundary between the User and SUD (system under development)

　　　　 UI layer “catches” the request

　　　　 The request is a system operation — public interface

　　　　 Model-View Separation principle says UI must not contain business logic

　　　　 Problem: UI应该把捕捉到的系统操作，发给领域层的哪个对象呢？
4.2 GRASP rule4: Controller

　　 Name: Controller 控制器

　　 Problem:

　　　　 What first object beyond the UI layer receives and co-ordinates (controls) a system operation

　　 Solution:

　　　　 Assign the responsibility to a class representing one of the following choices:

　　　　 1. Facade(外观) Controller:

　　　　　　 represents the overall system, a root object, a device that the object is running within, or a major sub-system

　　　　 2. Use Case or Session Controller（用例控制器、会话控制器）:

　　　　　　 represents a use case scenario within which the system event occurs
4.5 Controller — Observations 观察

　　 委托模式 Delegation pattern

　　 外部输入事件可以来自参与者（人）或者（其他系统）

　　 Facade — 相当于领域层对外部世界的“脸”

　　　　 Ex: Register

　　 Handler —处理系统某个明确的功能集，比如相关的一组系统事件

　　　　 Ex: ProcessSale
4.5 Controller — Facade

　　 外观控制器 Facade

　　　　 为子系统中的一组接口提供一个一致的界面

　　　　　　Provide a consistent interface for a set of interfaces in subsystem“cover” over the other layers of the application

　　　　 Abstraction of an overall physical unit

　　　　　　 — Register, PizzaShop

　　　　 The entire software system

　　　　　　 — POSSystem

　　　　 Abstraction of some other overall system or sub-system concept

　　　　　　 — MonopolyGame

　　 适用于

　　　　 相对较小的系统 relatively small systems

　　　　 有限数量的系统操作 and/or system with limited number of system operations

　　　　 在消息处理系统中，不能转发消息到可选的控制器时

　　　　　　in message handling system when can’t direct messages to alternative controllers

　　　　　　 — Internet application servers
4.5 Controller -- Session

　　 会话控制器

　　　　 一种纯虚构出来的概念 Pure Fabrication，即领域模型中没有的概念

　　　　 如， ProcessSaleHandler is not a domain concept in Domain Model

　　 会话控制器的应用场合

　　　　 当采用外观控制器会导致高耦合、低内聚时 When assigning to facade may lead to high coupling or low cohesion (“Bloat”)

　　　　 很多系统事件跨越多个不同的处理过程 Many system operations across different processes

　　　　 概念上容易理解和构建 Conceptually easier to understand and build

　　　　　　 一个会话控制器负责一类系统事件

　　 会话控制器的命名习惯 Session Controllers Naming conventions

　　　　　　 <UseCaseName> Handler or

　　　　　　 <UseCaseName> CoOrdinator or

　　　　　　 <UseCaseName>Session

　　　　 Use same controller class for all system operations in the use case scenario

　　　　 Session is a type of conversation between the actor and the SUD 新系统
4.7 Discuss: Controller — Benefits

　　 控制器模式的优点

　　　　 容易适应UI层的变化 Allows for easy change of UI and/or alternative UI

　　　　 领域层代码易于重用（因为UI层一般与应用关系密切）Allows for reuse of domain layer code (UI is usually application specific)

　　　　 有助于保证应用所需要的操作顺序 Helps ensure sequence of operation which may differ from UI input

　　　　 可以对系统的状态进行推理（UI层不保存系统状态）Can reason about system state — UI does not preserve state
4.8 Bloated(臃肿的) Controllers

　　 臃肿控制器的问题

　　　　 当一个外观控制器处理了大部分系统事件时 When have a facade controller handling all of many system events

　　　　 当一个控制器做了太多的事情，而不是委托给其他的对象去处理

　　　　　　When the controller performs many of the system operations instead of delegating

　　　　 当控制器掌握了太多的系统信息 When the controller has many attributes (much information) about the system

　　　　　　 which should be distributed to or duplicates from elsewhere

　　　　 导致：低内聚 Low cohesion — 做事不专注，做了太多的事

　　 臃肿控制器的解决方法

　　　　 增加更多的控制器 Add more controllers

　　　　 采用会话控制器替换外观控制器 “session controller” instead of facade

　　　　 控制器委托任务给别的对象，而不是自己做 Design the controller so that it delegates operations to other objects

　　　　 高内聚的理念 High Cohesion is itself a GRASP principle