CSC/ECE 517 Summer 2008/wiki3 2 mb: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 9: Line 9:
'''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.
'''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:'''  
'''Brief Summary:'''<br/>
Intent:  Provide a single class that implements an algorithm, which can be applied to many other classes.
Intent:  Provide a single class that implements an algorithm, which can be applied to many other classes.<br/>
Problem:  A set of classes need to perform an operation that differs for each of the classes.
Problem:  A set of classes need to perform an operation that differs for each of the classes.<br/>
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.
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.<br/>
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.
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.


Line 28: Line 28:
'''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.
'''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:'''
'''Brief Summary:'''<br/>
Intent:  Extend the functionality of a class.
Intent:  Extend the functionality of a class.<br/>
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.
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.<br/>
Solution:  Use a decorator class to wrap an object, extending the object’s functionality when it is required.
Solution:  Use a decorator class to wrap an object, extending the object’s functionality when it is required.<br/>
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.
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.


Line 47: Line 47:
'''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.
'''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:'''
'''Brief Summary:'''<br/>
Intent:  Simplify communication between objects within a complex system.
Intent:  Simplify communication between objects within a complex system.<br/>
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.
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.<br/>
Solution:  Add a mediator to the system that is responsible for handling the communication between objects within the system.
Solution:  Add a mediator to the system that is responsible for handling the communication between objects within the system.<br/>
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.
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.


Line 66: Line 66:
'''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.
'''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:'''
'''Brief Summary:'''<br/>
Intent:  Allow objects to send request to a variety of receivers without specific knowledge of those receivers.
Intent:  Allow objects to send request to a variety of receivers without specific knowledge of those receivers.<br/>
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.
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.<br/>
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.
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.<br/>
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.
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.


Line 85: Line 85:
'''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.
'''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:'''
'''Brief Summary:'''<br/>
Intent:  We want to allow the existence of a large number of similar objects within a sytem.
Intent:  We want to allow the existence of a large number of similar objects within a sytem.<br/>
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.
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.<br/>
Solution:  Share the information that the objects have in common, so more objects can be created with less overhead.
Solution:  Share the information that the objects have in common, so more objects can be created with less overhead.<br/>
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.
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.
   
   

Revision as of 08:32, 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
SourceMaking: Visitor Pattern
Introduction to the Visitor Pattern

Examples: While most explanation sites include examples, here are a couple more examples of the visitor pattern.
Java Design Patterns Visitor
learntechnology.net

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
The Decorator Design Pattern
Decorator Pattern

Examples: A few more examples of the decorator pattern.
Decorator Pattern Example
Java Design Patterns

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
Mediator
SourceMaking: Mediator

Examples: A couple more examples of the mediator pattern.
Java Design Patterns: Mediator
FluffyCat 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
Chain of Responsibility Pattern in Java
Chain of Responsibility Pattern

Examples: The following links provide a couple more examples of the chain of responsibility pattern.
Java Design Patterns: Chain of Responsibility
Refactoring to Patterns: Chain of Responsibility

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
The Flyweight Design Pattern
Flyweight Pattern

Examples: A couple more examples of the flyweight pattern.
Groovy: Flyweight Pattern
Java Design Patterns: Flyweight Pattern

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

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Summer_2008/wiki3_2_mb&oldid=15525"