ARE Design Patterns portable from one language to another? Of course they are. I’ve read some accounts that claim otherwise, but I’ve not found any design pattern that could not be used in any computer language that I’ve tried. (Maybe I’m just conversant in languages where design patterns do work, but I don’t think so.) Anyway, Chandima and I have been discussing doing a set of PHP design patterns, and I wanted one for a contact form I had done using PHP.
For this blog, though, I thought I’d use a translation from one of the design patterns we have on this blog so that you can more easily see the similarities and differences between ActionScript 3.0 and PHP in implementing the same design pattern.
Chain of Responsibility
As you may recall from our Chain Of Responsibility (CoR) post, the design pattern is used when you want to have a system that takes care of requests when you have different outcomes. In our original example, we added a helper class called Request, but otherwise we stuck with the basics of the CoR structure. Figure 1 shows the class diagram of the CoR we used in our initial post.
Figure 1: Chain of Responsibility Class Diagram
In this particular design pattern the Client class is a full-fledged participant in the pattern. Because Client classes are request objects themselves, it may seem odd to have a Request class. Just think of the Request class as a helper class that encapsulates requests for the Client.
Continue reading ‘PHP Chain of Responsibility Design Pattern from ActionScript 3.0′
The Chain of Responsibility (CoR) design pattern is used when you need a request handled by the most appropriate object for the request. You don’t need to worry about which object handles the request or even if they’ll handle it the same all the time. For example, suppose you have a constantly changing marketplace and the specs of your request change as well. Rather than building an application that links a specific request to a specific request handler the CoR pattern decouples the two so that when a request is sent, all you know is that the most appropriate object will handle it. Our department buys Flash drives in bulk from China. In the request for the drives I put in a set of criteria and send the request to my Chinese buyer. He is instructed to get the lowest price for the drives as long as they meet the specs in the required bulk. Now I don’t know which manufacturer will win the contract (which object will handle the request), but since I trust my agent in China, I am confident he’ll get the best price even though the price will vary depending on everything from the dollar’s exchange rate with China to the availability of Flash drives. Because so many variables change, I need the flexibility that changes with both the request and the request handler. That’s something like the way the CoR design pattern works—it takes a request and finds the most appropriate way to handle it.
Chain of Responsibility Overview
Because looking at a Class Diagram is useful for seeing the larger context of the design pattern, we’ll look at it first and then go about describing its features.
Figure 1: Chain of Responsibility Class Diagram
This looks fairly simple, and at the basic level it really is. Like some of the other design patterns, the Client is part of the pattern, and so it’s integral. At the center of the pattern is the Handler interface. For the time being, think of the interface as an abstract class because that is what is used in the initial example. The abstract class includes a function for setting successors in a chain and another to handle a request. Finally, the ConcreteHandler classes represent the specific and different classes that handle requests. Generally speaking, an application would include several ConcreteHandler classes, and each is set up in a chain to deal with requests where appropriate.
Continue reading ‘ActionScript 3.0 Chain of Responsibility Design Pattern: Decoupling Request and Request Handler’
Bill Sanders
Recent Comments