CSC/ECE 517 Fall 2007/wiki3 6 rs
Problem Description
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.
Introduction
There are various kinds of design patterns, to help us structure our code and component in order to solve some specific problem and to have effective code for the problem. Craig Larman has defined a set of design patterns which are called as the General Responsibility Assignment Software Patterns (GRASP). GRASP is a tool for learning object oriented design with principles. Controller pattern is one among the GRASP patterns.
There are several principles available for object oriented programming, but these principles cannot be considered as patterns. When we consider cohesion and coupling they are good design principles but do not belong to the group of design patterns. GRASP patterns defines two major types of responsibilities of the patterns-
Controller Patterns
Controller Patterns is one of the interesting patterns which answers the question – “What first object beyond the UI layer receives and coordinates or controls a system operations?” Or “Who handles the system event? “ Controller is the primary objects that are responsible for handling the message that is passed by the user through the UI. A controller is said to be present in a problem domain, but the controller is not part of the domain. It assigns responsibility to the other objects of that system. Also controls and coordinates between activities. In this case the controller satisfies the responsibilities of the GRASP patterns.
How does a controller work?
Controllers do not perform any work by themselves. The only task of the controller is to pass the responsibility to the domain object so that the object performs that task. It becomes the object’s responsibility to perform the work.
Types of controller patterns
Routinely there are some events that are triggered from outside the system, we are working on. Within the system we have an object that will receive this trigger. Here the object that receives the trigger need not handle the trigger. This trigger can be handled by any of the below classes • A class that represents the whole system, the sub system or the device. • A class that represents the use case scenario within the system where the event occurs. This defines the two kinds of the controller patterns.
Façade Controller – In cases when we do not handle lot of messages that’s needs to be managed by the controller, then the best way to handle she cases would be to have a single object to do all the work itself.Represents things like the whole system, a root object, a major sub system, a device that the software is running on, the base system on which the software is running, etc all these are the variations of the façade controller.
Examples for Façade Controller: Application built to manage contacts, address, and phone numbers – Address book Building an e-commerce website – store Building some games like chess.
Use Case controller – Use Case controllers are applied when there is lot of incoming message expected from the UI and these messages that are gathering are all unrelated. Usually they are represented in the form of use case scenario. They are used as handlers, coordinator, and sessions and so on. We cannot use the façade controller here are it would result in a risk of losing cohesiveness as in a façade controller we will be using a single controller. The best alternative is to use a controller per use case. Hence the use case or session controller can be used.
Example for a use case controller: When we consider the e-commerce application, we can best handle this application by having controller for each use case or session. Hence we could have controllers defined for handleReturn, ProcessSale, ProcessPayment and so on.
Understanding the Controller patterns with an example
In a general context:
In the above example when the cashier enters the values in the screen and submits the button, the action is moved from the UI layer to the Domain Layer. But in the domain layer who has to handle this action? In some cases the user interface objects such as the frames, windows objects etc act as the controller objects. These objects take the responsibility to process the action. But this approach reduces the cohesion in the class and increases the coupling. This leads to a poor design. An alternative to the above approach is to use a separate control object. This object delegates the responsibilities. Hence increases the cohesion and coupling making the system an effective one. It offers a effective layer to the architecture. The below example show this. The register class now delegates the work to the other objects based on the action it got from the user interface trigger.