CSC/ECE 517 Fall 2007/wiki3 5 ld: Difference between revisions
| Line 37: | Line 37: | ||
= Example of Creator Pattern = | = Example of Creator Pattern = | ||
Consider a simple part of a POS system as shown in the following class diagram: | Consider a simple part of a POS system as shown in the following class diagram: | ||
[ | |||
[[Image:Creator_1.jpg]] | |||
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: | |||
[[Image:Creator_2.jpg]] | |||
= Comparison with Factory Pattern = | = Comparison with Factory Pattern = | ||
Revision as of 01:12, 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.
Pros and Cons
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:
