The Mediator design pattern is easy to understand but tricky to implement. At the core of the Mediator pattern is a Mediator class that coordinates a set of different requests that are sent by objects. The objects are called Colleagues. The Colleagues let the Mediator know that they want to change, and the Mediator handles the change taking into account what effect the changes will have on the other colleagues. For example, in my car when I turn on the headlights, the panel lights dim. Something in my car tells the panel lights to dim when the headlights are switched on. The headlights represent one colleague and the panel lights, another. A Mediator tells the panel lights to turn on as soon as I start the car, and then when the headlights are switched on, the Mediator tells the panel lights to dim. If I turn off the headlight, the Mediator tells the panel lights to brighten up again. The colleagues never communicate directly with one another but instead through the mediator. The idea is to reduce the complexity by handling all of the requests in one place. This also insures loose coupling between the colleagues.
Put succinctly, the Mediator defines an object that encapsulates how a set of objects interacts. (GoF, 273). At the bottom of justifying such an encapsulation is the fact that a loosely coupled design often has many of the objects communicating with one another. The more loosely coupled, the greater the need to communicate. This can get messy if every object is telling every other object its current state and requesting them to adjust to whatever state they are entering. This would be like my headlights communicating directly with my panel lights letting them know whether they are on or off so that the panel lights can make the necessary adjustment. Add other “interested” objects, and pretty soon you have a rat’s nest to coordinate. In order to solve this dilemma, make a cleaner design and ease the interaction, the Mediator is introduced.
The Mediator’s Structure
To get started, the GoF present both a class and interactive diagram and we’ll do the same here in Figure 1:
Figure 1: Mediator Class and Interaction Diagrams
As the class diagram shows, two abstract classes, the Mediator and Colleague, each have concrete subclasses. However, a better view can be seen in the interaction diagram. You have a single concrete Mediator handling the interaction between several colleagues. In some cases, the interaction is one way and in others, two-way, but the Colleague instance always has an object reference to the Mediator. The Mediator may or may not have an object reference to the concrete colleague.
Continue reading ‘The Mediator Design Pattern: A Minimalist Example’
Let’s Not Perpetuate Misinformation
I’ve seen comments and blogs where the misinformed are leading the uninformed. The gist of the comments is of the nature that some ActionScript 3.0 design patterns are derived from Java or C# (or some other language.) Well, that’s like saying Java, C#, C++ and other languages got their patterns from SmallTalk. I’m sure that anyone who has begun with a design pattern for the first time needed to look at examples to get another view of the structure apart from a chart diagram. For those who used Gamma, et al for their starting point (which is just about everybody) then we’d have to claim that all design patterns are “borrowed” from SmallTalk. That’s just plain stupid in the context of what design patterns are all about. If no such examples, or good examples, can be found in ActionScript 3.0, then look in any other languages. The Gang of Four used SmallTalk for all of their examples. Some of these were quite helpful for finding the relationship between the classes/interfaces and can then be used to inform the developer what one might do with ActionScript 3.0. That’s it. Design Patterns are about relationships between classes and interfaces and it doesn’t matter what the language is they’re initially written in.
Continue reading ‘ActionScript 3.0: Not at the Children’s Table Anymore’
Jumping Out of Sequence: Memento Brings You Back
In the last installment on the Memento Design Pattern, you saw an abstract minimalist version to get an idea of how the Memento saved state and got it back again. I used a string variable as the “state” to be saved and retrieved without breaking encapsulation. This time around I used the Memento to solve a more practical and definitely real world problem. How to allow a user to jump around a multimedia online presentation without getting lost. To get an idea of how this works, take a look at a working example of this application at:
http://www.sandlight.com/memento/
When you run the application, you can jump to another level, and then just click the Return to Last button, and it will take you back to your jump point. Also, I put up the zip file to save time in getting all of the code in. Figure 1 shows what you can expect to see:
Figure 1
You can download it at:
Download the FMS Memento Zip File
All of the files are in Flash CS3 format, but the ActionScript files are pretty easy to port over to Flex.
Continue reading ‘ActionScript 3.0 Memento Design Pattern: Flash Media Server 3 Application’
The Undo Pattern
One of my most-used keyboard combinations is Ctrl+Z to undo just about anything from a program line of code to a graphic drawing. Fortunately for all of us, we can undo just about anything and get back to a state where things were okay—or at least not as bad. The Memento Design Pattern is designed to save state without violating encapsulation. Violating encapsulation could be a problem because encapsulation helps insure the application’s reliability and extensibility. Saving state in itself is pretty simple—just dump the state’s value into a variable, array or object and retrieve it when you need it. However, doing so exposes the state to other objects that might affect it in ways you cannot control.
An Enigma
While the purpose of the Memento is about as clear as you can get, it’s implementation was somewhat of an enigma to me. First, it is one of only three patterns that do not have an interface or abstract class participants (the Singleton and Facade are the others). I suppose that’s not that big of a deal, but those participants in the pattern always seemed to be the glue that holds everything together. That does not mean that the Memento pattern has no interfaces; just not classes identified as such. (More on this further on.) Second, in looking at every Memento design I could find, they seemed to be all over the map—including a couple that added interface participants in the pattern. Like most patterns, I like to begin with a minimalist example to reveal its structure. Also, I like to stick very close to The Gang of Four’s structure; so part of the problem is probably my inherent conservatism when it comes to design patterns. Some of the Memento examples I looked at had me hard-pressed to believe that they were actually Mementos as described by Gamma and his associates. Everyone likes the undo idea, but I’m not so sure that they implement their Mementos with the kind of state encapsulation envisioned by the pattern’s architects.
Sticking Close to the Memento
To get started, take a look at the Memento class diagram. I included labels in red for the nature of the relations between the three main classes and the dog-eared boxes as well:
Figure 1:Memento Class Diagram
The Gang of Four describes the interfaces in terms of the relations between the three participants as wide and narrow relative to the Memento class. First, the Caretaker class acts like a guardhouse storing the mementos and keeping them from other objects giving it a narrow interface to the Memento class. Second, the Originator has a wide interface so that it can restore itself to a previous state and create mementos that will save a given state.
Continue reading ‘ActionScript 3.0 Memento Design Pattern: Encapsulating Saved States’
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’
Latest Comments
RSS