Archive for the 'Design Patterns' Category

The Iterator Pattern: Flexible implementation of collections

Published
by
Chandima
on September 4, 2008
in Iterator Pattern
. 8 Comments

We tend to think of the iterator pattern as simply a mechanism to access a collection of items in some sort of order. However, the motivation for the iterator pattern goes quite a bit beyond this everyday requirement. It is specifically designed to hide how you decide to structure the collection, but still provide a uniform interface to traverse and access its elements. We will look at a couple of examples where we change how the collection is implemented but keep the client oblivious to the change.

Let’s take a look at the class diagram to determine the relationships between the classes in the iterator pattern.


Continue reading ‘The Iterator Pattern: Flexible implementation of collections’

ActionScript Proxy Design Pattern : The Virtual Proxy (A Minimal Abstract Example)

Published
by
Bill Sanders
on August 26, 2008
in ActionScript, Design Patterns, Flash, Flex, OOP and Proxy Pattern
. 2 Comments

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.
Continue reading ‘ActionScript Proxy Design Pattern : The Virtual Proxy (A Minimal Abstract Example)’

An ActionScript Bridge Design Pattern: Flexibility Making Backdrops

Published
by
Bill Sanders
on August 22, 2008
in ActionScript, Bridge Pattern, Design Patterns, Flash, Flex and OOP
. 3 Comments

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.
Continue reading ‘An ActionScript Bridge Design Pattern: Flexibility Making Backdrops’

The Mediator Design Pattern: A Minimalist Example

Published
by
Bill Sanders
on July 7, 2008
in ActionScript, Design Patterns, Flash, Flex and OOP
. 0 Comments

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:

Mediator
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’

ActionScript 3.0: Not at the Children’s Table Anymore

Published
by
Bill Sanders
on April 20, 2008
in Design Patterns, OOP and Uncategorized
. 7 Comments

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’