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 different kinds of design patterns, to help us structure our code and component in order to solve some specific problem and to have effective code written 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"[3]? Or "Who handles the system event?"[3] 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
These Controllers are used when we do not handle lot of messages that’s needs to be managed by the controller, then the best way to handle these cases would be to have a single object to do all the work itself.Represents objects 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 as 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:
Image take from reference [3]
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.
The below image taken from reference [3]
Advantage: Controller pattern and Cohesion
Cohesion in object oriented is defined as a “measure of how strongly- related and focused are the various responsibilities of a software module” [1]. In programming languages, high cohesion is desired. The advantage of high cohesion includes the robustness, reliability, reusability and understandability of the software. As the cohesion decreases the software becomes more difficult to manage, maintain, test, reuse and also to understand.
In GRASP patterns, an object with high responsibility that does very little work is said to be highly cohesive. In a controller, the controller does very little work; it only assigns the work to the other domain objects that are responsible in processing it. Hence using these controller patterns increase the cohesion of the system. Cohesion and coupling go together. Hence the increase in the cohesion reduces the coupling effect making the system more efficient.
Code snippet for a controller pattern
Consider a community server blog. In a blog user can enter text, post the text, reviewer can give feedback and also the weblogs can be saved. Hence four controllers are defined to receive these events.
Handles system messages with regarding feedback for blog posts.
Handles system messages that are entered to the blogs.
Handles system messages associated with individual blog posts.
Handles system messages associated with individual blogs. public class WeblogPosts // WeblogPost class { private WeblogPosts(){} // ... public static PostSet GetPosts(BlogPostQuery query, bool cacheable) // this receives the query and then processes its resposibility { //makes some checks at this point. string key = cacheable ? query.Key : null; PostSet ps = null; if(cacheable) ps = CSCache.Get(key) as PostSet; if(ps == null) { //from the WeblogDataProvider it creates that instance and hands over the query for its processing. WeblogDataProvider wdp = WeblogDataProvider.Instance(); ps = wdp.GetPosts(query); if(cacheable) // it then uses this handler to do the insert in to the WeblogData. CSCache.Insert(key,ps,30, System.Web.Caching.CacheItemPriority.Low); } return ps; } // ... }
Above we have four controller defined to receive the event for the corresponding tasks. In the above example, we can see how the usercontrol uses the controller class, WeblogPosts, to obtain the main post and comments for a particular BlogID and PostID to be displayed to the user. We can see the userControl and the controller class both collaborating.
Some External links
Example 1 : http://davidhayden.com/blog/dave/archive/2005/04/01/918.aspx
In the above link the author explains the Controller pattern with a webPost examples. The code snippet is provided in the link which explain the concept well. It is easy to understand the concept.
Example 2 : http://davidhayden.com/blog/dave/archive/2005/04/03/933.aspx
A code snippet in this link shows the implememtation of the Controller Pattern
Example 3 : http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html
The above link is very helpful in understanding this pattern. The author explains the concept with the help of class diagrams and sequence diagrams.
Example 4 : http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/Controller.html
The pictorial representation in this link help us understand the advantages of the Controller Pattern. In the above link the author shows two ways of implementing a functionality. One design is without the Controller Pattern and the other with Controller patter. And later shows how the Controller Pattern is advantages.
References
[1] http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29
[2] http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx
[3] http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/GRASPpatterns.html
[4] http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/Creator.html
[5] http://davidhayden.com/blog/dave/archive/2004/11/28/648.aspx
[6] http://www.davidhayden.com/blog/dave/archive/2004/12/10/680.aspx
[7] http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
[8] http://davidhayden.com/blog/dave/archive/2004/11/19/631.aspx