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

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

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

POS SYSTEM : Cashier enterItem(itemID, quantity)

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

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

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?

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

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

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

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

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.

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.

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.

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

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

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.

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.

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.