Controller (GRASP)

GRASP Pattern: Controller

 * Name | **Controller** |
 * Problem | What first object beyond the UI layer receives and coordinates a system operation? |
 * Solution | Assign the responsibility to either... |
 * | - A facade controller. representing the overall system and handling all system operations, or |
 * | - A use case controller, that handles all system events for a single use case. |

From the Model-View Separation Principle, we know the UI objects should not contain application or "business" logic. Therefore, once the UI objects pick up a mouse event, they need to //delegate// the request to domain objects in the domain layer.


 * Option 1:** Represents the overall "system", or a "root object" - such as an object called MonopolyGame.


 * Option 1:** Represents a device that the software is running within - this option appertains to specialized hardware devices such as a phone or a cash machine.


 * Option 2:** Represents the use case or session. Consider the example of a Monopoly game. The use case that the playGame system operation occurs within is called //Play Monopoly Game//. Thus, a software class such as PlayMonopolyGameHandler (appending "...Handler" or "...Session" is an idiom in OO design). This option is reasonable if there are only a few system operations (more on the trade-offs in the principle High Cohesion).

Guidelines

 * Controller should //delegate// to other domain layer objects.
 * Use facade controller when...
 * There are limited number of system operations, or
 * When operations are coming in over a single "pipe".
 * Use use case controller when a facade whould be bloated (low cohesion!).