CSC/ECE 517 Fall 2007/wiki3 6 pm

Take the Controller pattern (which we did not cover in class) and catalog the information on it available on the Web. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.

Design Patterns

A Design Pattern refers to a named description of a problem and a solution that can be applied in different contexts. Patterns are proven solutions to common problems.

A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it. This is done by defining a set of rules which describes how to solve the problem at hand.

GRASP Patterns

GRASP refers to General Responsibility Assignment Software Patterns. It includes a systematic approach to Object Oriented Design, while assigning responsibilities to classes.

GRASP Patterns are more of responsibility driven design Responsibilities of an Object include two types : Knowing and Doing Doing responsibilities of an object include: 1.Doing something itself, such as creating an object or doing a calculation 2.Initiating action in other objects 3.Controlling and coordinating activities in other objects

Knowing responsibilities of an object include: 1.Knowing about private encapsulated data (know thyself, presume not God to scan) 2.Knowing about related objects 3.Knowing about things it can derive or calculate

The GRASP Patterns include:

• Information Expert
• Creator
• Controller
• Low Coupling
• High Cohesion
• Polymorphism
• Pure Fabrication
• Indirection
• Protected Variations

Some of these, such as "Low Coupling" and "High Cohesion" are merely good design principles, and not design patterns.

The Controller Pattern

Introduction

The Controller pattern addresses the question: Who handles a system event? It assigns responsibilities for handling system events to different objects.

Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. These events should be handled by classes representing one of the following choices:

• A class that represents the overall system, device, or subsystem (facade controller).
• A class that represents a use case scenario within which the system event occurs. These are often named <usecasename>Handler, <usecasename>Controller, <usecasename>Manager,and so forth.

To choose between facade and use-case controllers:

1. The Facade controller is suitable when there are few system events.

2. The Use-case controller is applicable when there are many system events and the facade controller would have become too large and incohesive.

Wikipedia succinctly states: "The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers)"

Benefits

• Reuse of domain layer software by plugging in various interfaces
• It is possible to control out-of-sequence system events

Examples

Example 1

Reference 1 contains an excellent description of the controller pattern.

 The controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method 
 for the system operation".

• A system event is said to be an event generated by an "external actor"

• A system operation refers to the response of the system to a system event.

The figure below shows allocation of different operations

Example 2

The game of Monopoly is an excellent example of a controller pattern. Actors, such as the human player in Monopoly, generate UI events (such as clicking a button with a mouse to play a game or make a move). The UI software objects (such as a JFrame window and a JButton) must process the event and cause the game to play. When objects in the UI layer pick up an event, they must delegate the request to an object in the domain layer.

The problem in this case can be formulated as follows: What first object beyond the UI layer should receive the message from the UI layer?

As per the controller pattern the solution is as follows: Assign the responsibility to an object representing either of following: - Represents the overall “system” – a root object - Represents a use case scenario within which the system operation occurs.

Example 3

This article contains an E-Commerce example of the Controller Pattern. The author classifies controllers as Use case Controllers and Facade Controllers.

Use case controllers are useful to handle messages from the User Interface Layer when there is little coupling between messages. A facade controller to handle all messages will not suffice in this case.

The E-Commerce application in the example considers the following messages:

   Get Categories
   Get Product in Category X
   Get Items in Shopping Cart
   Add Item to Shopping Cart

The first 2 messages are related to a ProductCatalog to ProductCatalogHandler and the last 2 messages are related to the shopper's cart to ShoppingCartHandler:

   ProductCatalogHandler
         -Get Categories
         -Get Product in Category X
   ShoppingCartHandler
         -Get Items in Shopping Cart
         -Add Item to Shopping Cart

ProductCatalogHandler and ShoppingCartHandler are highly cohesive, embodied by the Controller Pattern.

Example 4

Reference 6 contains the following solution to the problem of who handles the system event: "If a program receives events from external sources other than its graphical interface, add an event class to decouple the event source(s) from the objects that actually handle the events."

The author also mentions the benefits of using the Controller Pattern as an increased potential for reuse. It leads to decoupling between the external sources of events and the internal event handlers.

Consider the example of buying items at a supermarket. The cashier enters the items to be purchased and generates a bill for the customer to make the payment at the end of the sale. The system events include:

 enterItem()
 endSale()
 makePayment()

The problem can be phrased as: Who is responsible for enterItem()?

Using the Controller Pattern to solve our problem, we can choose among the following:

• The overall system [POST]
• The overall business(sub-system) [STORE]
• Someone in the real world who is active in the task [CASHIER]
• The artificial handler of all system events in the use case [BuyItemsHandler]

The choice made should reflect high cohesion and low coupling, as shown below, in which the UI layer is decoupled from the problem domain.

Example 5

This Blog mentions some examples of the Controller Pattern in the context of blogs. It demonstrates how the controller class beyond the UI layer "hands off" the message to another domain layer object to act upon the message.

Another related article disambiguates between the Controller Pattern and the Model-View-Controller Architecture. The author defines the controller as "the first object beyond the UI layer that is responsible for receiving or handling a system operation message". As entailed above, the controller is the coordinator responsible for delegating work to other objects that actually accomplish the task at hand.

See Also

1. Applying UML and Patterns: Craig Larman

2. Grasp Design Patterns

3. GRASP Patterns

References

1. GRASP Patterns

2. Wikipedia link to GRASP

3. Blog on GRASP Controller Pattern

4. E-Commerce example

5. Controller responsibility

6. Presentation on GRASP

7. DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS

8. Presentation on Design Patterns

9. Monopoly Example