1. TK2023 Object-Oriented Software Engineering
CHAPTER 13e
GRASP Patterns: Controller

2. GRASP PATTERNS: CONTROLLER
Problem
What first object beyond the UI layer receives and coordinates (“controls”) a system operation?

3. Treat system as a black box : System : Cashier makeNewSale( )
enterItem(itemID, quantity)
endSale( )
makePayment(amount)
Treat system
as a black box

4. POS SYSTEM
: Cashier
enterItem(itemID, quantity)

5. POS SYSTEM : C : E : A : B Controller : D Domain Layer UI Layer
: Cashier
enterItem(itemID, quantity)
: A
: B
Controller
: D
Technical
Services
Layer
Domain
Layer
UI Layer
Foundation
Layer

6. Solution
Assign the responsibility to a class representing one of the following choices:
a façade controller
represents the overall “system”, a “root object”, a device that the software is running within, or a major subsystem.
Examples: MonopolyGame, ATMTerminal.
a use case or session controller
represents a use case scenario within which the system event occurs, often named <UseCaseName>Handler, <UseCaseName>Coordinator, or <UseCaseName>Session.
Use the same controller class for all system events in the use case scenario.
Example: ManageUsersHandler

7. EXAMPLE OF APPLICATION
: System
: Cashier
makeNewSale( )
enterItem(itemID, quantity)
endSale( )
makePayment(amount)
What object should be the controller for the system events represented in this SSD?

8. The Controller pattern suggests the following possibilities:
Façade controller
Register OR
POSSystem OR
Use case controller
ProcessSaleHandler / ProcessSaleSession
Which should we choose?

9. If we choose Register as the controller for handling the system operation enterItem…
POS SYSTEM
: Cashier
enterItem(itemID, quantity) …
: Register
: ?
Controller
Domain
Layer
UI Layer

10. Two examples of allocating system operations:
Using one façade controller to handle all system operations:
Register
endSale()
enterItem()
makeNewSale()
makePayment() …
makeNewReturn()
enterReturnItem()

11. Using a use case controller for each use case:
ProcessSaleHandler
HandleReturnsHandler
endSale()
enterItem()
makeNewSale()
makePayment()
makeNewReturn()
enterReturnItem() …

12. DISCUSSION
Use the Controller pattern to guide in choosing a handler for system events.
UI layer shouldn’t contain application logic. Thus, UI layer objects should not handle system events. They should delegate the task to objects in other layers (e.g. domain layer).
Often, we will want to use the same controller class for all the system events of one use case.
This will enable the controller to maintain information about the state of use case. Example: makePayment should come after endSale.
Different controllers may be used for different use cases.

13. Façade controllers
A façade controller represents the overall system, device or a subsystem.
The idea is to choose some class name that suggests a cover (i.e. a façade) over the other layers of the application. It provides the main point of service calls from the UI layer down to other layers.
Façade controllers are suitable when there are not “too many” system events.

14. Use case controllers
If you choose use case controllers, you will have a different controller for each use case.
Note that use case controllers are not domain objects. They are artificial constructs created to support the system.
You should consider using use case controllers if using a façade controller leads to designs with low cohesion or high coupling.
When there are many system events across different processes, a use case controller is a good choice. The handling of those events is distributed among separate classes. Furthermore, it allows keeping track of the progress of the current scenario.

15. EXAMPLE OF IMPLEMENTATION
Design A
Refer MyApplet_Design_A.java
In this design, all system operations are handled in the MyApplet_Design_A class (a UI layer object).
: MyApplet_Design_A
: Cashier
makeNewSale()
POS System

16. EXAMPLE OF IMPLEMENTATION
Design B (applies the Controller pattern)
Refer MyApplet_Design_B.java
In this design, the handling of system operations is delegated to the Register class (a non-UI layer object).
: MyApplet_Design_B
: Cashier
makeNewSale()
POS System
: Register

17. THE ISSUE OF BLOATED CONTROLLERS
Remember not to over-assign responsibilities to controllers. This leads to bloated controllers which have low cohesion.
Guideline: Normally, a controller does not do much work itself. It coordinates or controls activities; work that needs to be done is delegated to other objects.

18. Indications of bloating:
There is only a single controller class receiving all system events in the system, and there are many of them.
The controller itself performs many of the tasks necessary to fulfill the system event, without delegating the work.
A controller has many attributes, and it maintains significant information about the system or domain.

19. Two cures: Add more controllers
Employ use case controllers instead of façade controllers.
Design the controller so that it primarily delegates the fulfillment of each system operation responsibility to other objects.