Archive for the 'OOP' Category

ActionScript 3.0 Memento Design Pattern: Encapsulating Saved States

Published
by
Bill Sanders
on January 24, 2008
in Design Patterns, Flash, Flex, Memento Pattern and OOP
. 8 Comments

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:
Memento Class Diagram
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’

What Design Pattern Next?

Published
by
Bill Sanders
on January 15, 2008
in OOP
. 14 Comments

It’s Already 2008
*Note: This is just for reader comments.

As we forge ahead in the new year, we’d like to add useful Design Pattern material to this blog. Right now, the plan has been to add design patterns that we did not cover in our book. Our book covered the following:

Creational Patterns
Factory, Singleton

Structural
Decorator, Adapter, Composite

Behavioral
Command, Observer,Template Method, State, Strategy

Multiple Patterns
Model-View-Controller, Symmetric Proxy

Our blog so far we have included detailed descriptions and examples for:

  • Composite
  • MVC using the PureMVC framework
  • Flyweight
  • Chain of Responsibility
  • Memento
  • Mediator

One goal is to have a complete set of Design Patterns in ActionScript 3.0. Moving toward that goal, I’ve been going through the “Leftover Design Patterns” in the Head First Design Patterns book finding ones that I’ve not seen in ActionScript 3.0. For me, at least, it’s more interesting than ones that have already been done either in our book or elsewhere in ActionScript 3.0. Currently, that leaves the following list of “leftovers” that we’ve not examined:

  • Bridge
  • Builder
  • Interpreter
  • Mediator
  • Memento
  • Prototype
  • Visitor

There are other Design Patterns as well that were not covered in our book, but the leftover list seems to be a good starting place. So, that being said, we’d like to know how you’d like us to proceed. Rank the following from 1 to 10 (1=No thanks … 10=Yes, I want that!). Place your rankings in the comments section.

1. Keep working our way through the “Leftover list”. (Include which Design Pattern you’d like to see next.)
2. General discussions about design patterns and their concepts (e.g., relations between patterns, different alternative pattern designs, OOP concepts found in design.)
3. Simple abstract examples to best see the structure and concepts involved.
4. Design pattern examples with practical application examples even though they are more complex and do not as clearly show the structure and concepts.
5. “Head” discussions about different ideas for programming in ActionScript 3.0 for OOP and design patterns but not any particular design.
6. Preference: Flex, Flash, Both

Also, if you have other ideas you’d like to see included on the blog, just add them to your comments.

ActionScript 3.0 Chain of Responsibility Design Pattern: Decoupling Request and Request Handler

Published
by
Bill Sanders
on January 14, 2008
in ActionScript, Chain of Responsibility Pattern, Design Patterns, Flash, Flex and OOP
. 2 Comments

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’

Unconditional Contest

Published
by
Bill Sanders
on December 31, 2007
in ActionScript and OOP
. 16 Comments

Win A Free Book
A while back, I had a little piece on getting rid of conditional statements. Since that time, I’ve been writing scripts that have reduced the number of conditionals significantly, and we thought it might be fun to have a little contest with the prize, a free, signed copy of our design pattern book.
Continue reading ‘Unconditional Contest’

Minimalist MVC example using the PureMVC Framework

Published
by
Chandima
on December 27, 2007
in Design Patterns, Flash, MVC Pattern and OOP
. 19 Comments

Several months ago, I was looking for a framework that would streamline AS3 application development. Cairngorm and PureMVC were the most mature frameworks out there and I remember being particularly impressed with PureMVC mainly due to the solid documentation that came with it. Cairngorm may be robust, but I just couldn’t get my head wrapped around it by glancing at the docs and examples. In contrast, PureMVC came with a Conceptual Diagram that explained the framework using the design patterns that I was familiar with. Cairngorm does have similar diagrams that explain its microarchitecture, but it exemplifies my initial thoughts — I just couldn’t get a quick, big picture understanding of it easily. Not only has Cliff Hall done a masterful job on the PureMVC framework, but the effort he’s put into the documentation really underscores the importance of documentation and diagrams on dissemination and adoption.

Cairngorm or PureMVC?
Recently, Ali Mills and Luke Bayes made a presentation on Flex Application Frameworks. Their choices essentially boiled down to Cairngorm and PureMVC and concluded that PureMVC came out on top. However, I highly recommend that developers watch the whole presentation as many enterprise developers in the audience made comments that challenged the easy differentiation of the two frameworks. Having the backing of a stable organization like Adobe, as is the case with Cairngorm, means a lot for enterprise development. Also, this post on Bill Lane’s blog and several comments implying that PureMVC is much harder to learn than Cairngorm got me thinking if a really simple application would help scaffold the transition to PureMVC.

I’ve implemented the minimalist example from the MVC chapter of our book (available as a free download from Adobe Devnet) using the PureMVC framework. Now this is not a full-fledged application, but a very minimal example meant to explain the inner workings of the PureMVC framework. Before diving in, a brief introduction to some of the important aspects of the framework will help. This was the hard stuff that I had to internalize before starting out. These concepts are more eloquently explained in much greater detail by Cliff Hall in the framework documentation.

Continue reading ‘Minimalist MVC example using the PureMVC Framework’