ActionScript 3.0 Design Patterns

During the summer I was heads down on a book project that got more urgent as the summer progressed. As a result, I’m a bit late on a suggested revision of the Protection Proxy sent in by Gil Amran way back in June.

In the original article, I questioned the practice of hauling a reference to the output UI all the way through the program. However, focusing on the design pattern, I didn’t concern myself with certain details that would have been optimal in a larger sense. Also, I don’t like using helper classes when trying to focus on the basics of a pattern. So, I just put in bare essentials hoping that readers will better be able to see how the pattern works.

However, I’m always looking for better ways of programming, and to misquote Ralph Waldo Emerson,

Build a better proxy and the world will beat a path to your door.

So download Gil’s code, and let’s take a look at it:

A Better Mousetrap

The revision of the Proxy was by Gil Amran and here, in Gil’s words, is what was changed:

I’ve changed few things:

1. I used AbsSubject and not the interface. (Abstract class)
2. I’ve overrided the clone method in the 2 custom events.
3. I’ve re-dispatched any events that came from he realSubject

Further Gil notes,

The AbsSubject extends EventDispatcher, and there’s no way to avoid that. Because the actual loading takes time and works with events, using callbacks might be another way to solve this and not use events.

In comparing Gil’s proxy with the original, the key differences are in handling events. Figure 1 is a file class diagram of Gil’s protection proxy you can compare to the original:

The two helpers classes function to deal with event handling and dispatch.
Read more…

On June 30, 2010 I met with the Flash Coders New York (FCNY). I walked over to the meeting site from Grand Central Station—it’s a straight shot up Park Ave., dogleg at Broadway and Bob’s your uncle! It’s right there near 4th on Mercer in a joint called Think Coffee. (East Village area near NYU.) I was lugging my Mac PowerBook and it and the case weighted 11 pounds. (After the two mile hike, my computer felt considerably heavier. If you plan to go, you’ll find that the subway— #6 to Brooklyn Bridge—from Grand Central is easier.)

Making Changes to the Original Protection Proxy

FCNY meets in the basement room at Think Coffee that reminded me of a (smoke free) anarchist’s safe house. (I was expecting to see Sacco and Vanzetti there.) They helped me hook up my PowerBook to a projector, and off we went. Having found myself in a perfect storm of doing the author edits of a Flash Catalyst book and starting on another new book, I was pressed for time; so I took the protection proxy from this blog and changed the proxy participant to include an algorithm that would filter out different “levels” of access. The level of sophistication of the algorithm and the added classes for different levels of access were quite simple. However, the point is to focus on the design pattern and not my acumen at writing algorithms. (If you don’t like the algorithms, you can always re-write them and send them in.) You can download the package by clicking the download button—the .zip file includes the PPT/KeyNote pages as well.

What was most exciting for me was the fact that the Protection Proxy was so easy to change. Here was a program with several different classes, and I had to add new functionality in a hurry that did several different things that would not crash my program. Essentially, I was adding three new concrete RealSubject classes that would work with the current program and make changes in the Proxy (SubProxy) to filter through three different “level of access” options. I knew that if I followed the interface rules, no matter what algorithm I used, it’d work. Figure 1 shows the class diagram of the revised Protection Proxy (from the FCNY presentation.)

The three RealSubject participants (International, National, Local) are pretty much the same except that each loads a different text file. However, as long as each maintains the interface, no matter how different the algorithms are, everything happily hums along.

Read more…

I’ll be at the Flash Coders New York (FCNY) weekly meeting at Think Coffee, 248 Mercer St. (NYC) on Wednesday, June 30 (Time: 7-9pm) to talk about ActionScript 3.0 Design Patterns. The plan is to look at some of the fundamental principles of design patterns and implementations with ActionScript 3.0. The Protection Proxy used in combination with PHP and multiple levels of access is the planned application that will be discussed plus any other ActionScript 3.0 Design Pattern of interest. Bill

The images that people use on dating sites may not exactly represent who they are. So instead of putting in a real picture, they may use a proxy that is better looking, younger (or older), and generally more likely to attract a date. The Proxy Design Pattern deals with object access. In our book, we employed an unusual proxy, the Symmetric Proxy Pattern that uses a remote proxy. In fact, it uses mirrored proxies to access two different objects simultaneously. Our example showed how to use it with Flash Media Server, and so probably not a lot of developers use it as a model for understanding a Proxy pattern. However, on this blog we provided a virtual proxy that should be a clear and simple example of a Proxy design pattern. So, we covered two of the three Proxy designs. The sole remaining type is the Protection Proxy, and that’s what we’re going to look at now. (You can run it and download the files using the buttons below:)

The Easiest Proxy

Of all of the Proxy designs, the Protection Proxy is very simple both in terms of implementation and concept. The Client makes a request to the Proxy, and the Proxy decides whether to give the Client access to the Subject. Where more than a single Subject is available, the Proxy decides on the level of access. For example, we started off with an example of a dating site. Some users have no access to the dating site until they sign up as a customer. Basically, the Proxy denies them all access to the subject. Once they sign up, they may be given access only to a specific gender. For example, the girls may only be given access to boys if that’s who they’re interested in meeting. The Proxy controls that access. Also, they may be given access only to change their own profile; again controlled by the Proxy. Of course the site administrator needs total access so that he can make sure that no one is posting materials that they shouldn’t be. (When I posted that I was an Astronaut, Rock Star who owns a Silicon Valley software company, the administrator changed it—and without my permission!.)

This design requires only three participants to implement : Subject (interface), Proxy and RealSubject with the Client making a request through the Subject interface to the Proxy. Figure 1 shows the Proxy class diagram shows and the different relationships:

The sequence is unique in that the request, while for the RealSubject, goes through the Proxy as shown in the object diagram in Figure 2:

As you can see, the Proxy design is pretty straightforward, and given the three modes (remote, virtual, and protection), it’s versatile. However, in looking at it, it doesn’t seem to do too much in terms of loosening up code and reusability. According to the GoF,

The Proxy pattern introduces a level of indirection when accessing an object. The additional indirection has many uses, depending on the kind of proxy: p. 210

So the key to understanding the Proxy pattern is indirection. We need to consider indirection a bit more, which we begin on the next section.
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…