CSC/ECE 517 Fall 2007/wiki3 5 ld: Difference between revisions
| Line 44: | Line 44: | ||
== Knowing and Doing == | == Knowing and Doing == | ||
<table width = "80%"> | <table width = "80%"> | ||
<tr><th align = "left" valign = "top" width = "40%" >1. Understand member data</th><th align = "left" valign = "top" >1. Perform a directly useful action <br> | <tr><th align = "left" valign = "top" width = "40%" >1. Understand member data</th><th align = "left" valign = "top" >1. Perform a directly useful action <br> »Change some data (Assign, calculate, create an object,…)</th></tr> | ||
<tr><th align = "left" valign = "top" width = "40%">2. Understand what you (an object) can do yourself <br>Calculate something <br>Create other objects</th><th align = "left" valign = "top">2. Initiate actions in other objects</th></tr> | <tr><th align = "left" valign = "top" width = "40%">2. Understand what you (an object) can do yourself <br>Calculate something <br>Create other objects</th><th align = "left" valign = "top">2. Initiate actions in other objects</th></tr> | ||
<tr><th align = "left" valign = "top" width = "40%">3. Understand related objects</th><th align = "left" valign = "top">3. Control/coordinate other objects <br>They might change some data <br>If they don’t, what do they do? <br>Analogy: top brass, middle brass, and everyone else</th></tr> | <tr><th align = "left" valign = "top" width = "40%">3. Understand related objects</th><th align = "left" valign = "top">3. Control/coordinate other objects <br>They might change some data <br>If they don’t, what do they do? <br>Analogy: top brass, middle brass, and everyone else</th></tr> | ||
Revision as of 02:27, 20 November 2007
Topic
Take the Creator pattern and catalog the information on it available on the Web. Explain how it is different from the Factory pattern. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.
Introduction
GRASP
Most design patterns are used by programmers to better the code structure and facilitate their coding and maintenance. However, Creator Pattern belongs to a different kind of design pattern: the GRASP pattern. The purpose of this pattern is to describe a proper way to perform tasks.
The GRASP pattern was first described by Craig Larman in his book: Applying UML and Patterns, 3ed. GRASP stands for General Responsibility Assignment Software Patterns. He mentioned that "The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology". Hence GRASP is more like a toolset to aid programmers in designing object-oriented programs.
Examples of different patterns/principles used in GRASP are:
- Information Expert
- Creator
- Controller
- Low Coupling
- High Cohesion
- Polymorphism
- Pure Fabrication
- Indirection
- Protected Variations
All these patterns answer some software problem, and in almost every case these problems are common to most every software development project, thus they don't exist to facilitate new information but to better document and standardize old, tried-and-true programming principles in object oriented design.
Creator Pattern
The Creator pattern solves the problem: Who should be responsible for creating a new instance of some class? There are several cases to consider. Let A and B be objects. Larman offers the following.
- B aggregates A objects. That is, there is a whole-part relationship between B and A. A objects are considered to be a part of B objects.
- B contains A objects. This is a stronger whole-part relationship, also called composition. With composition, the A objects have no existence outside of their relationship with B objects.
- B records instances of A objects.
- B closely uses A objects.
- B has the initializing data that will be pass to A when it is created (thus B is an Expert with respect to creating A).
In these cases, B is a creator of A objects. If more than one option applies, prefer a class B which aggregates or contains class A.
GRASP Concept
Meaning of the Name
General Responsibility Assignment Software Patterns
- General = Abstract; widely applicable
- Responsibility = Obligations, duties
- Assignment = Giving a responsibility to a module
- Software = Computer code
- Patterns = Regularities, templates, abstraction
Knowing and Doing
| 1. Understand member data | 1. Perform a directly useful action »Change some data (Assign, calculate, create an object,…) |
|---|---|
| 2. Understand what you (an object) can do yourself Calculate something Create other objects | 2. Initiate actions in other objects |
| 3. Understand related objects | 3. Control/coordinate other objects They might change some data If they don’t, what do they do? Analogy: top brass, middle brass, and everyone else |
Example of Creator Pattern
Consider a simple part of a POS system as shown in the following class diagram:
You will raise the question as who should be responsible for creating a SalesLineItem instance? Since the Sale object contains the SalesLineItem, the Sale is a good candidate for this responsibility. The sequence diagram showing this is:
Comparison with Factory Pattern
When creation requires significant complexity, such as using recycled instances for performance reasons, conditionally creating an instance from one of a family of similar classes based upon some external property value, and so forth, you may not want to use the Creator pattern. You might want to delegate the creation to a class that is specifically designed for such a purpose. Consider the Factory pattern.