Controller

Problem

What first object beyond the UI layer receives and coordinates ("controls") a system operation?

A controller is the first object beyond the UI layer that is responsible for receiving or handling a system operation message.

Solution

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

· Represents the overall "system," a "root object," a device that the software is running within, or a major subsystemthese are all variations of a facade controller.

· Represents a use case scenario within which the system event occurs, often named <UseCaseName>Handler, <UseCaseName>Coordinator, or <UseCaseName>Session (use case or session controller).

o Use the same controller class for all system events in the same use case scenario.

o Informally, a session is an instance of a conversation with an actor. Sessions can be of any length but are often organized in terms of use cases

Guideline

Normally, a controller should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It does not do much work itself.

Benefits

· Increased potential for reuse and pluggable interfaces. These benefits ensure that application logic is not handled in the interface layer. The responsibilities of a controller could technically be handled in an interface object, but such a design implies that program code and the fulfillment of application logic would be embedded in interface or window objects. An interface-as-controller design reduces the opportunity to reuse logic in future applications, since logic that is bound to a particular interface (for example, window-like objects) is seldom applicable in other applications. By contrast, delegating a system operation responsibility to a controller supports the reuse of the logic in future applications. And since the application logic is not bound to the interface layer, it can be replaced with a different interface.

· Opportunity to reason about the state of the use case. Sometimes we must ensure that system operations occur in a legal sequence, or we want to be able to reason about the current state of activity and operations within the use case that is underway. For example, we may have to guarantee that the makePayment operation cannot occur until the endSale operation has occurred. If so, we need to capture this state information somewhere; the controller is one reasonable choice, especially if we use the same controller throughout the use case.