CSC/ECE 517 Fall 2007/wiki3 6 pm: Difference between revisions
No edit summary |
mNo edit summary |
||
| Line 25: | Line 25: | ||
The Controller pattern addresses the question: Who handles a system event? | The Controller pattern addresses the question: Who handles a system event? | ||
Sometimes, an event is initiated from an external source. A class receives the event, but it may not handle the event. | 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 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, | * 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. | ||
and so forth | |||
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= | |||
http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html contains an excellent description of the controller pattern. According to the author, one must assign the responsibility for handling a system event to a class that: | ==1== | ||
[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html Reference 1] contains an excellent description of the controller pattern. According to the author, one must assign the responsibility for handling a system event to a class that: | |||
1. Represents the overall system, device, or subsystem. | 1. Represents the overall system, device, or subsystem. | ||
| Line 47: | Line 47: | ||
The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE) | The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE) | ||
==Examples== | ==Examples== | ||
| Line 57: | Line 59: | ||
[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns] | [http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns] | ||
[http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) Wikipedia link to GRASP] | |||
Revision as of 03:52, 14 November 2007
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?
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.
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
1
Reference 1 contains an excellent description of the controller pattern. According to the author, one must assign the responsibility for handling a system event to a class that:
1. Represents the overall system, device, or subsystem. 2. Represents a use case scenario in which the system event occurs.
- 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 controller is "A non-user interface object responsible for receiving or handling a system event, and that defines the method for the system operation".
The website also contains a diagram showing the general context of the Controller, depicted below. (INCLUDE DIAGRAM HERE)
Examples
See Also
Applying UML and Patterns: Craig Larman