DOC PREVIEW
UMD CMSC 433 - Chain of Responsibility Pattern

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1Behavioral Patterns• Patterns that are most specifically concerned with communication between objects.– The Iterator pattern formalizes the way we move through a list of data within a class.– The Observer pattern defines the way a number of classes can be notified of a change.– The Mediator defines how communication between classes can be simplified by using another class to keep all classes from having to know about each other.– The Chain of Responsibility allows an even further decoupling between classes, by passing a request between classes until it is recognized.– The Template pattern provides an abstract definition of an algorithm.– The Interpreter provides a definition of how to include language elements in a program.– The Strategy pattern encapsulates an algorithm inside a class.– The Visitor pattern adds function to a class.– The State pattern provides a memory for a class’s instance variables.– The Command pattern provides a simple way to separate execution of a command from the interface environment that produced it.2CMSC 433 – Programming Language Technologies and ParadigmsSpring 2007Chain of Responsibility PatternApr. 10, 20073What is it?• The Chain of Responsibility pattern allows a number of classes to attempt to handle a request, without any of them knowing about the capabilities of the other classes. • It provides a loose coupling between these classes; the only common link is the request that is passed between them. • The request is passed along until one of the classes can handle it.4A Classic Example• One example of such a chain pattern is a Help system, where every screen region of an application invites you to seek help, but in which there are window background areas where more generic help is the only suitable result. • When you select an area for help, that visual control forwards its ID or name to the chain.5A Classic Example• Suppose you selected the “New” button. – If the first module can handle the New button, it displays the help message. – If not, it forwards the request to the next module. – Eventually, the message is forwarded to an “All buttons” class that can display a general message about how buttons work. – If there is no general button help, the message is forwarded to the general help module that tells you how the system works in general. – If that doesn’t exist, the message is lost and no information is displayed.6Note that…• The chain is organized from most specific to most general.• There is no guarantee that the request will produce a response in all cases.7Use the Chain of Responsibility when…• You have more than one handler that can handle a request and there is no way to know which handler to use. The handler must be determined automatically by the chain.• You want to issue a request to one of several objects without specifying which one explicitly.• You want to be able to dynamically modify the set of objects that can handle requests.8A Simple Example• Consider a simple system for display the results of typed in requests. • These requests can be– Image filenames– General filenames– Colors– Other commands• In three cases, we can display a concrete result of the request, and in the last case, we can only display the request text itself.9The UI• We type in “Mandrill” and see a display of the image Mandrill.jpg. • Then, we type in “FileList” and that filename is highlighted in the center list box. • Next, we type in “blue” and that color is displayed in the lower center panel. • Finally, if we type in anything that is neither a filename nor a color, that text is displayed in the final, right-hand list box.10We Need…•The addChain method adds another class to the chain of classes. •The getChain method returns the current class to which messages are being forwarded. • These two methods allow us to modify the chain dynamically and add additional classes in the middle of an existing chain. •The sendToChain method forwards a message to the next object in the chain.11Lets Start Coding!• Lets start with a Chain interface.12Imager Class• Our Imager class is derived from JPanel and implements our Chain interface. • It takes the message and looks for “.jpg” files with that root name. • If it finds one, it displays it.13Code of Imager Class14Code of Imager Class (cont…)15ColorImage Class• In a similar fashion, the ColorImage class simply interprets the message as a color name and displays it if it can. • This example only interprets 3 colors, but you could implement any number.16Code of ColorImage Class17The Other Two Classes• Both the file list and the list of unrecognized commands are JList boxes. • Since we developed an adapter JawtList in a previous lecture to give JList a simpler interface, we’ll use that adapter here. • The RestList class is the end of the chain, and any command that reaches it is simply displayed in the list. • However, to allow for convenient extension, we are able to forward the message to other classes as well.18RestList Code19FileList• The FileList class is quite similar and can be derived from the RestList class, to avoid replicating the addChain and getChain methods. • The only differences are that it loads a list of the files in the current directory into the list when initialized, and looks for one of those files when it receives a request.20FileList Code21FileList Code (contd…)• The Xfile class is a simple child of the File class that contains a matchRoot method to compare a string to the root name of a file.22Linking the Chain…• Finally, we link these classes together in the constructor to form the Chain23A Tree• A Chain of Responsibility does not have to be linear. • A more general structure is a tree with a number of specific entry points all pointing upward to the most general node.24For Example…25Disadvantage• However, this sort of structure seems to imply that each button, or its handler, knows where to enter the chain. • This can complicate the design in some cases, and may preclude the need for the chain at all.• There is little reason for that complexity -- you could align the classes into a single chain, starting at the bottom, and going left to right and up a row at a time until the entire system had been traversed.26The “Tree” Chain27More Complex Requests• The request or message passed along the Chain of Responsibility may well be a


View Full Document

UMD CMSC 433 - Chain of Responsibility Pattern

Documents in this Course
Trace 1

Trace 1

62 pages

Reflection

Reflection

137 pages

Testing

Testing

25 pages

Paradigms

Paradigms

10 pages

Testing

Testing

17 pages

Java RMI

Java RMI

17 pages

Java RMI

Java RMI

17 pages

Java RMI

Java RMI

17 pages

Trace 1

Trace 1

46 pages

Jini

Jini

4 pages

Final

Final

15 pages

Java RMI

Java RMI

13 pages

Testing

Testing

16 pages

Load more
Download Chain of Responsibility Pattern
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Chain of Responsibility Pattern and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Chain of Responsibility Pattern 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?