ActionScript 3.0 Design Patterns

The bigger and more complex a system based on subsystems gets, the more difficult it is for a client to make requests and get what is expected. The Facade acts as an interface to simplify communication with the elements that make up the subsystem and the client. So instead of communicating with all of the components of the subsystem, the client interacts with a single component, the Facade.

The class diagram for the Façade looks a good deal different from most other design patterns. The classes that make up the subsystem are intentionally vague to represent any subsystem. The problem, though, is clearly illustrated by the network of possible connections between the classes in the subsystem and how a client might run into problems when it needs to interact with them all. Figure 1 shows a modified Façade class diagram. In the original GoF diagram, the client is not listed as a participant—only the Façade and the subsystem classes. However, following the Freemans’ diagram (with some slight adjustments of my own to make it closer to the GoF diagram) I included a client but made it implicit.

Figure 1: Facade Class Diagram
Read more…

The Gang of Four divide up the Proxy design pattern into three types: remote, virtual, and protection. In our book, Chandima and I used a remote proxy in the Symmetric Proxy example(Chapter 13). Each player in a game over the Internet was able to make simultaneous moves using the remote proxy representing an opponent on their own system. That leaves the virtual and protection proxies to cover, and we’ll start with the virtual proxy in this article.

Avoiding Repetition

Our university uses a software package called Blackboard for course administration. It’s quite handy, and I use it a good deal. As a Web-based application requiring a login, the initial login is time-consuming as the application gathers up all of the information it has stored for all of my classes. However, if I quit the program and return within a certain time window, I don’t have to go through login again. More importantly, the application does not have to reload all of the materials for me again. When you consider that hundreds of faculty and thousands of students are all using the same system on a daily basis, the ability to re-use previously loaded materials is a huge savings.

For the most part, design patterns, do not improve the performance of your programs with a few exceptions, such as the Flyweight pattern previously discussed on this blog. I believe that the virtual proxy design pattern is another one of those patterns that improves the performance of your program because your application is not constantly re-doing something expensive (time-consuming) that’s already been done. Most of the examples, including the one provided by GoF, are of loading graphics. Once loaded, most graphics do not have to be reloaded for repeated display after the initial loading. So, rather than reload graphics or files of any kind, the virtual proxy design first checks to see if your materials are already loaded, and if they are, it uses the extant materials. If not, it simply calls the real loader and loads up what’s required. Any application that has multiple users over the Web (which is most programs) the virtual proxy can significantly improve the performance of the program because it reuses loaded materials.

How the Proxy Design Pattern Works

The Proxy pattern does not have different class diagrams for the different types of proxies. Figure 1 shows the pattern diagram used for all variations of the pattern.

Figure 1: Proxy Class Diagram

The client is not a participant, but it is included to indicate where it sends its request. It is loosely coupled to the participants following the path illustrated in Figure 2.

Figure 2: Proxy Object Diagram

The proxy is used to check and see if a real subject is required, and if so, it sends the request to the real subject. However, if the proxy can handle the request without using the real subject, it will do so. In effect, the proxy acts like a gatekeeper. It inspects all requests, and if it can deal with the requests it does, but no requests go directly to the real subject from the client. Figure 2 shows the intermediary position of the proxy. The only problem with the object diagram is that it looks like the proxy is a stop along the way to the real subject, but depending on the application, the request may never get to the real subject.
Read more…

Like most of the design patterns we’ve dealt with both in our book and on this blog we like to start with a minimalist example and then provide a more concrete and useful example. With the Bridge design pattern, the example is fairly minimalist, but it has been designed to create graphic backdrops for video objects. So, while not exactly minimalist and certainly not abstract, the Bridge example here is still fairly simple. (Well, at least as simple as design patterns ever get.) Besides, it accomplished something I needed.

Bridge Over Untroubled Waters

With most design patterns I’ve found that their abstract concepts are clearer than their actual creation. (The Mediator design pattern in this blog is a good example.) However, with the Bridge, I found that the concept was a bit muddled, but making a Bridge design pattern that actually accomplished something useful was relatively simple. To get started, take a look at the class diagram in Figure 1:

Figure 1: Bridge Class Diagram

The intent of the Bridge pattern is to decouple an abstraction from its implementation so that the two can vary independently. (GoG 151) If you don’t think about that much, it sounds like a good idea to keep an application from grinding its gears when a change is made in either the abstraction or implementation. The Freemans (Head First Design Patterns, pp. 612-613) have a great example—a universal remote control. The remote control is the abstraction and a TV set is the implementor. Concrete implementors are the different brands of TVs. As new technology arises, the remote control can be updated with new gizmos. Likewise, the TV sets can also be updated and different brands will have their own unique features. A good Bridge design will allow each to be changed without breaking the other. So far so good.
Read more…

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. (Before starting the project, you might want to download the files by clicking the Download button.)

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.
Read more…

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.

Read more…

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.
Read more…

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.
Read more…

No Conditionals Please
At the 2007 OOPSLA Conference in Montreal, a professor from New York City was explaining how he taught his introductory computer science classes. Students would be given a problem and they’d go through a number of steps until the solution failed. He found that most of the failures occurred as students became entangled in ever more elaborate conditional statements.

To resolve this problem, he told them they could not use conditional statements, and the general results were both better solutions and better coding. My first reaction in one of the breakout sessions was “No way!” Back in the day, one of my favorite pastimes was working out sort algorithms, and I find it hard to imagine working out even a simple bubble sort without using conditional statements. Other examples quickly came to mind, and I dug in to defend the use of conditional statements from if to switch (and everything in between).

Then he mentioned three magic words: State Design Pattern. This got my undivided attention because of the work I’d done with them and more generally, State Machines. Each class in a State Design Pattern is made up of a set of functions that launch when a certain state in invoked. No if‘s in sight. Triggers launch different states, and the state classes provide the context for the particular state. In other words, the triggers just call the state class desired.

Aside from the State Design Pattern, can a decent program be written without a single conditional statement when more than one condition needs to be considered? I think it can be, and I’m beginning to think that much better programs can be developed if conditionals are kept out. To illustrate a simple decision-making process with no conditional statements, the following program has a decision-making process based on user input.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Unconditional extends Sprite
	{
		private var men:String;
		private var women:String;
		private var Button1:Button;
		private var Button2:Button;
 
		public function Unconditional ()
		{
			men="Men";
			women="Women";
 
			Button1=new Button();
			Button1.label=men;
			Button1.x=200, Button1.y=150;
			addChild (Button1);
			Button1.addEventListener (MouseEvent.CLICK,doMen);
 
			Button2=new Button();
			Button2.label=women;
			Button2.x=200, Button2.y=200;
			addChild (Button2);
			Button2.addEventListener (MouseEvent.CLICK,doWomen);
		}
		private function doMen (e:MouseEvent)
		{
			trace ("Whatever is appropriate for men");
		}
		private function doWomen (e:MouseEvent)
		{
			trace ("Whatever is appropriate for women");
		}
	}
}

That was a simple program, and it could have been handled with a single method using a conditional statement.

But It Would Have Been Easier….
In thinking about this, you may be thinking of a long list of cases used in a switch statement or even a simple if...else sequence make a program possible. (I mentioned sort algorithms, and I’m sure you can think of others where you just had to have conditionals.) Often, (in fact usually) it’s easier to use conditional statements than to work out a lot of code that does the same thing. However, no one who took up design patterns was looking for an easier way to create code. In my experience, there’s nothing easy about design pattens except when it comes to the all important task of updating and changing a program. So, because it’s easier probably is not the best argument to preserve conditional statements–at least for readers of this blog.

Why Conditionals?
Rather than ask why not conditionals, I think we need to ask why conditionals? Why indeed? If a programmer wants something to happen given an event, ranging from user input to data from a Web service, the event should trigger the actions directly rather than first filter through a conditional statement. It cuts out a step (the conditional scratching its head) and goes right to the solution. So why even use conditionals? Yes, we’re all used to them, but most of us were used to either sequential or procedural programming before tackling OOP or design patterns. If we can get along without conditionals, and keep a direct link between the state to call an action and the action, it would seem to be a better programming structure. Then, when we want to make changes, the events are not tied into a conditional statement, and we don’t have to untangle the conditional webs we weave.

Comments Please
I’d really like to get some feedback on this idea. If you’re thinking, That’s the stupidest thing I’ve ever head, I’ll save you the trouble–that was my initial thought, and it didn’t really help the discussion. Rather, I’m hoping to find some ideas about this — with or without the State Design Pattern. Mainly, I’m interested in this in the context of design patterns in general; specifically how conditionals or lack of them relate to the different kinds of connections between classes. Do they really get in the way of delegation, composition, aggregation and inheritance? Are they simply a shortcut and add little to good structure? Or not?

Aggregation Aggravation

In the first installment of this Flyweight Saga, I noted that the relationship between a Flyweight and Flyweight Factory class is one of aggregation. The initial example shows that the Retrieve method in the Factory class returns an instance of IFlyweight, meeting the requirement of the proper connection between the two classes. In looking at one example in Java, (even with modest Java skills), the program clearly did not have such a relationship between the Factory and Flyweight. In fact, it claimed, that an object’s extrinsic state can be shared by classes. Now, maybe that was unfortunate wording because the big feature of the Flyweight design pattern is that the Flyweight can be a shared object, but only the intrinsic state can be shared. (Maybe the author meant that extrinsic states can be shared between classes in a Flyweight design pattern, and that’s probably right but is not a key feature of the pattern.)
Read more…

Extrinsic States
In the first part of the Flyweight Saga, I had the idea that a Flyweight design pattern would be a good idea because it would be useful for cranking out buttons on the stage. However, the comments by the readers have led me to reconsider that idea; so it’s back to the drawing board. This revised Flyweight is going to focus on adding an extrinsic state parameter. Also, I got rid of all but one of the concrete Flyweights and am now down to the FlyButton class only in order to focus on extrinsic states.

Keep in mind that this process is a matter of working out the specific sense of a Flyweight pattern more than it is to show the optimum example. In going over some Flyweight materials from MIT, they suggested having a grasp on other, simpler patterns like the Observer and even MVC before tackling the Flyweight. This was both comforting and worrisome!

Extrinsic State Parameter

To get back on track (somewhat), this new Flyweight includes a parameter for extrinsic states in the Flyweight interface. Because the state is extrinsic, it changes with the Flyweights context. As discussed briefly in Part I of this saga, the extrinsic state changes with the context while the intrinsic state does not. Thus, the extrinsic state is not shareable (a shared object) and the intrinsic is. A concrete class can be sharable or not, but it cannot be if it does not store the intrinsic state. However, both sharable and non-sharable concrete Flyweights can exist. The following summary might be helpful.
Extrinsic state

Cannot be shared
Depends on flyweight’s context
Client is responsible for supplying extrinsic state when needed

Intrinsic state

Can be shared
Stored (inherent) in the flyweight
Does not depend flyweight’s context

Read more…