CSC/ECE 517 Fall 2007/wiki3 5 ld: Difference between revisions
(35 intermediate revisions by 2 users not shown) | |||
Line 3: | Line 3: | ||
= Introduction = | = Introduction = | ||
== GRASP == | == GRASP Pattern== | ||
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. | 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 [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) 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. | The [http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design) 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: | Examples of different patterns/principles used in GRASP are: | ||
Line 43: | Line 43: | ||
== Knowing and Doing == | == Knowing and Doing == | ||
<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> »Change some data (Assign, calculate, create an object,…)<br></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<br></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<br></th></tr> | |||
</table> | |||
= Example of Creator Pattern = | = Example of Creator Pattern = | ||
Line 54: | Line 59: | ||
= Comparison with Factory Pattern = | = 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. | 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, which helps determine the the responsibility for creating objects with specail consederations such as complex creation logic. | ||
= Examples for | The main difference between creator pattern and factory pattern is: | ||
Creator Pattern creats an objects which is closely related to the created object. Meanwhile, Factory Pattern is designed solely to create other kinds of object. A factory, as an alternative to a constructor in a class, is a member of a different class. The objects created by factory pattern don't have to know precisely what class they are instances of. | |||
= Examples for Factory Pattern= | |||
This example is from the [http://www.itec.uni-klu.ac.at/~harald/ds2001/rmi/factory/factory2.html here]. | |||
Examples of Factories in the Real World: | |||
The Bank | |||
When you go to the bank to make a deposit to your account, you don't walk up to a vault, pull out a drawer with your name on it, drop in your money, shut the drawer and leave. Think about how you originally established, or opened, the account. You probably went to the bank, spoke with an Account Manager, and signed some papers. In return, they gave you some checks, a passbook, or a bank card so you could access your account in the future. | |||
The Account Manager is an example of a factory. The person or Automated Teller Machine (ATM) that acts as account manager controls the creation of and/or access to individual accounts. | |||
The Library | |||
Let's think about how a book, compact disk, or video tape gets from the library shelf into your home. Before you can check out any material, you must first get a library card from the librarian. In this case, the librarian could be viewed as a library card factory because the librarian controls the creation of new library card instances. | |||
Once you have a library card, you can go into the library, and without any further fuss, just walk out with all your materials, right? Of course not. Before you can walk out of the library without setting off the alarm system, you must check out the book, CD, or video tape you wish to take home. So you present your library card to, you guessed it, the librarian, who will use your card to access the library database to see if you owe any late fees, and to register these new materials as having been leased to you. In this case, the librarian could be seen as a book factory because the librarian controls your access to the books. | |||
= Reference = | = Reference = | ||
Line 69: | Line 90: | ||
*[http://www.ibm.com/developerworks/rational/library/may06/krebs/ Patterns in Action] | *[http://www.ibm.com/developerworks/rational/library/may06/krebs/ Patterns in Action] | ||
*[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2005/moreGRASP.pdf moreGRASP] | *[http://class.ee.iastate.edu/berleant/home/Courses/SoftwareEngineering/CprE486fall2005/moreGRASP.pdf moreGRASP] | ||
= External Links = | |||
http://www.itec.uni-klu.ac.at/~harald/ds2001/rmi/factory/factory2.html | |||
http://www.javacamp.org/designPattern/factory.html | |||
http://en.wikipedia.org/wiki/Factory_method_pattern | |||
http://www.allapplabs.com/java_design_patterns/factory_pattern.htm | |||
http://gsraj.tripod.com/design/creational/factory/factory.html |
Latest revision as of 23:27, 2 December 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 Pattern
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, which helps determine the the responsibility for creating objects with specail consederations such as complex creation logic.
The main difference between creator pattern and factory pattern is: Creator Pattern creats an objects which is closely related to the created object. Meanwhile, Factory Pattern is designed solely to create other kinds of object. A factory, as an alternative to a constructor in a class, is a member of a different class. The objects created by factory pattern don't have to know precisely what class they are instances of.
Examples for Factory Pattern
This example is from the here.
Examples of Factories in the Real World:
The Bank
When you go to the bank to make a deposit to your account, you don't walk up to a vault, pull out a drawer with your name on it, drop in your money, shut the drawer and leave. Think about how you originally established, or opened, the account. You probably went to the bank, spoke with an Account Manager, and signed some papers. In return, they gave you some checks, a passbook, or a bank card so you could access your account in the future. The Account Manager is an example of a factory. The person or Automated Teller Machine (ATM) that acts as account manager controls the creation of and/or access to individual accounts.
The Library
Let's think about how a book, compact disk, or video tape gets from the library shelf into your home. Before you can check out any material, you must first get a library card from the librarian. In this case, the librarian could be viewed as a library card factory because the librarian controls the creation of new library card instances. Once you have a library card, you can go into the library, and without any further fuss, just walk out with all your materials, right? Of course not. Before you can walk out of the library without setting off the alarm system, you must check out the book, CD, or video tape you wish to take home. So you present your library card to, you guessed it, the librarian, who will use your card to access the library database to see if you owe any late fees, and to register these new materials as having been leased to you. In this case, the librarian could be seen as a book factory because the librarian controls your access to the books.
Reference
- Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process
- GRASP Wikipedia
- Applying GRASP to Object Design
- Patterns - GRASP
- Patterns and Principles
- Design Patterns
- A&P Web Consulting
- Preview of Patterns in Java Volume 2
- Patterns in Action
- moreGRASP
External Links
http://www.itec.uni-klu.ac.at/~harald/ds2001/rmi/factory/factory2.html
http://www.javacamp.org/designPattern/factory.html
http://en.wikipedia.org/wiki/Factory_method_pattern
http://www.allapplabs.com/java_design_patterns/factory_pattern.htm
http://gsraj.tripod.com/design/creational/factory/factory.html