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.

GRASP Patterns

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

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.

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)"

Description

Description1

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 website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)

• • • • • • Should we format it as Desc/Example or separate them ?

Description2

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.

Description3

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.

Description4

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.

See Also

Applying UML and Patterns: Craig Larman

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.