CSC/ECE 517 Summer 2008/wiki3 2 mb: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
==Assignment== | ==Assignment== | ||
Peruse the Patterns Almanac for additional patterns that seem appropriate to cover in CSC/ECE 517. Explain why the patterns are appropriate for students to learn, and if possible, link to training materials (explanations, examples, etc.) for covering them. Your reviewers should rate your choices on how much value they will add to the course! | Peruse the [http://www.smallmemory.com/almanac/ Patterns Almanac] for additional patterns that seem appropriate to cover in CSC/ECE 517. Explain why the patterns are appropriate for students to learn, and if possible, link to training materials (explanations, examples, etc.) for covering them. Your reviewers should rate your choices on how much value they will add to the course! | ||
==Introduction== | ==Introduction== |
Revision as of 08:16, 25 July 2008
Assignment
Peruse the Patterns Almanac for additional patterns that seem appropriate to cover in CSC/ECE 517. Explain why the patterns are appropriate for students to learn, and if possible, link to training materials (explanations, examples, etc.) for covering them. Your reviewers should rate your choices on how much value they will add to the course!
Introduction
CSC/ECE 517 students explore numerous design patterns during a semester. This web page discusses five more design patterns that may be appropriate to include within a course regarding object-oriented languages.
Visitor Pattern
Appropriateness: The visitor pattern facilitates the decoupling of an algorithm and the objects that the algorithm is applied to. Multiple visitors, implementing different algorithms, can be applied to a set of objects without having to alter the objects when new algorithms are implemented. Thus, independent visitors can be created that implement different algorithms to act on multiple objects. This is useful when the algorithm must behave differently depending upon the object it is applied to. For instance, a pretty-print visitor may be created to handle a set of classes that have different requirements for printing based upon the class.
Brief Summary: Intent: Provide a single class that implements an algorithm, which can be applied to many other classes. Problem: A set of classes need to perform an operation that differs for each of the classes. Solution: Allow the classes that need to perform a similar algorithm the ability to accept a visitor, and then let the visitor apply an algorithm upon all the classes that need the functionality. Implementation: Create a class (visitor) capable of performing an algorithm upon many other classes (visitee’s). The visitor will define numerous visit methods, where each method signature will contain a different visitee class parameter that determines which method should be visited. The visitee’s that need to access the this class will define an accept method, which takes a visitor as a parameter and then calls the visit method of that class and passes itself as one of the arguments, so the appropriate visit method will be called.
Explanations: The following web sites provide explanations of the visitor pattern. Wikipedia: Visitor Pattern http://en.wikipedia.org/wiki/Visitor_pattern SourceMaking: Visitor Pattern http://sourcemaking.com/design_patterns/visitor Introduction to the Visitor Pattern http://www.cs.ucr.edu/~lgao/teaching/visitor.html
Examples: While most explanation sites include examples, here are a couple more examples of the visitor pattern. Java Design Patterns Visitor: http://www.fluffycat.com/Java-Design-Patterns/Visitor/ learntechnology.net http://www.learntechnology.net/content/patterns/visitor-pattern.jsp
Decorator Pattern
Appropriateness: The decorator pattern provides a way to extend the functionality of a class by wrapping that class with another class, as opposed to subclassing the original class. This allows objects to have their functionality extended at run-time, whereas inheritance must usually occur at compile-time. With this pattern, objects can be wrapped to include the appropriate functionality when needed and those same objects can be re-wrapped to include different functionality as the needs of the object change.
Brief Summary: Intent: Extend the functionality of a class. Problem: The functionality of a class needs to be extended, but what type of extension may be required may not be known prior to run-time. Solution: Use a decorator class to wrap an object, extending the object’s functionality when it is required. Implementation: Create classes (decorator’s) that implement the same interface as the classes (decoree’s) they are meant to operate upon. When a decoree needs to add additional functionality to its objects, those objects can then be wrapped with the appropriate decorator to modify their functionality when the need for the new functionality arises.
Explanations: Different explanations of the decorator pattern can be found on the following web sites Wikipedia: Decorator Pattern http://en.wikipedia.org/wiki/Decorator_pattern The Decorator Design Pattern http://exciton.cs.rice.edu/JavaResources/DesignPatterns/DecoratorPattern.htm Decorator Pattern http://www.patnys.com/archive/2008/04/21/decorator-pattern.aspx
Examples: A few more examples of the decorator pattern. Decorator Pattern Example http://blogs.msdn.com/darronj/archive/2006/08/15/701244.aspx Java Design Patterns http://www.allapplabs.com/java_design_patterns/decorator_pattern.htm
Mediator Pattern
Appropriateness: The aim of the mediator pattern is to reduce coupling between the classes of a software system. Communication between objects is handled by the mediator, thus classes do not have to concern themselves with how they communicate with each other, only with how they communicate with the mediator. When new classes are added to the system, or when existing classes within the system are modified, the manner in which they communicate with the other objects in the system is not important. Only the communication with the mediator may require changes.
Brief Summary: Intent: Simplify communication between objects within a complex system. Problem: As more classes are added to a software project the intercommunication between the various objects becomes more complicated, and maintaining the code to perform interactions within the system becomes difficult to oversee. Solution: Add a mediator to the system that is responsible for handling the communication between objects within the system. Implementation: Create a class (the mediator) that contains the control logic regarding communication between the various objects of the software system. As new objects are added to the system they must only concern themselves with when they need to update the mediator of state changes, as well as how they respond to request from the mediator.
Explanations: The following web sites provide explanations of the mediator pattern. Wikipedia: Mediator Pattern http://en.wikipedia.org/wiki/Mediator_pattern Mediator http://home.earthlink.net/~huston2/dp/mediator.html SourceMaking: Mediator http://sourcemaking.com/design_patterns/mediator
Examples: A couple more examples of the mediator pattern. Java Design Patterns: Mediator http://www.allapplabs.com/java_design_patterns/mediator_pattern.htm FluffyCat Design Patterns: Mediator http://www.fluffycat.com/Java-Design-Patterns/Mediator/
Chain of Responsibility Pattern
Appropriateness: The chain of responsibility pattern is another pattern used to reduce coupling between classes within a software system. This allows the sender of a request to be unaware of the receivers of the request. The sender of a request could explicitly define all of its receivers, but the chain of responsibility alleviates the need for such knowledge of the receivers. Not only does a sender not need to know about receivers, but the receivers may be altered dynamically by adding new receivers, removing existing receivers, or changing the order in which receivers obtain the request.
Brief Summary: Intent: Allow objects to send request to a variety of receivers without specific knowledge of those receivers. Problem: An object within a software system may need to send information to another part of the system, yet the object does not wish to define the specific receivers of the message. The object may not even know what the specific receivers are. Solution: Create a chain of responsibility including multiple objects, each of which may choose to handle the request or pass the request along to the next object in the chain. Implementation: Create multiple classes (handlers) that are arranged in an order of preferred precedence (chain of responsibility). When classes (request senders) need to have an event handled, they pass their request to the first handler in their chain of responsibility. The request is then examined by the first handler, where it will either be handled by the handler or passed along to the next handler in the chain of responsibility.
Explanations: The following websites contain descriptions of the chain of responsibility pattern. Wikipedia: Chain of Responsibility Pattern http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Chain of Responsibility Pattern in Java http://www.javabeat.net/tips/101-chain-of-responsibility-pattern-in-java.html Chain of Responsibility Pattern http://alumni.media.mit.edu/~tpminka/patterns/CoR.html
Examples: The following links provide a couple more examples of the chain of responsibility pattern. Java Design Patterns: Chain of Responsibility http://www.allapplabs.com/java_design_patterns/chain_of_responsibility_pattern.htm Refactoring to Patterns: Chain of Responsibility http://www.codeproject.com/KB/architecture/ChainOfResponsibilityPatt.aspx
Flyweight Pattern
Appropriateness: Many software systems require the creation of many similar objects. If these objects share state data a significant performance increase can be attained by sharing the state data that they have in common. While most of the patterns on this page are concerned with the reduction of coupling, this pattern is concerned with increasing efficiency within a system that must contain numerous objects which share common information.
Brief Summary: Intent: We want to allow the existence of a large number of similar objects within a sytem. Problem: If each object is allowed to maintain a unique copy of information that can be shared, the system will quickly consume more resources than are available. Solution: Share the information that the objects have in common, so more objects can be created with less overhead. Implementation: Create an object (flyweight) that can be populated with data for immediate use. Allow objects (full weight) to contain only unique information and the understanding of how to access shared data, within the flyweight object, when the object must be used.
Explanations: The following sites provide explanations for the flyweight pattern. Wikipedia: Flyweight Pattern http://en.wikipedia.org/wiki/Flyweight_pattern The Flyweight Design Pattern http://exciton.cs.rice.edu/JavaResources/DesignPatterns/FlyweightPattern.htm Flyweight Pattern http://c2.com/cgi/wiki?FlyweightPattern
Examples: A couple more examples of the flyweight pattern. Groovy: Flyweight Pattern http://groovy.codehaus.org/Flyweight+Pattern Java Design Patterns: Flyweight Pattern http://www.allapplabs.com/java_design_patterns/flyweight_pattern.htm
Web Site Reviews
Notice that a treatment of all the design patterns on this page can also be found within the Head First Design Patterns textbook that is required for this course.
Please rate the preceding design patterns on how much value you feel they would add to this course, from 0(no value) to 5(high value).
Hint: Copy and paste the following into your additional comments section and change the numbers to reflect your opinion.
Value Rating Visitor: 4 Decorator: 5 Mediator: 2 Chain of Responsibility: 3 Flyweight: 4