CSC/ECE 517 Fall 2007/wiki3 6 pm: Difference between revisions
No edit summary |
No edit summary |
||
Line 23: | Line 23: | ||
==Introduction== | ==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. Larman suggests that 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. | |||
If you choose the second case, you might want to use the came controller class for all system in | |||
the particular use case scenario. The only reason for not doing so is that the class becomes too | |||
complex and it becomes better to delegate the work. | |||
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. 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== | ==Examples== | ||
=See Also= | =See Also= | ||
Applying UML and Patterns: Craig Larman | |||
=References= | =References= | ||
[http://www.augustana.ab.ca/~mohrj/courses/2003.fall/csc220/lecture_notes/responsibilities.html GRASP Patterns] |
Revision as of 03:46, 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. Larman suggests that 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. If you choose the second case, you might want to use the came controller class for all system in the particular use case scenario. The only reason for not doing so is that the class becomes too complex and it becomes better to delegate the work.
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. 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