Protection Proxy with DataLoaded Helper Classes

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:

Figure 1:Protection Proxy with Event Dispatch Classes

After looking at both implementations of the Protection Proxy, you will see that the key issue is the delay in loading the text file and sending either the data from the text file or an error message back to the user in some kind of UI. Using the trace() statement resolves most of these issues because you don’t need any kind of link back to a source where your UI is instantiated. However, in an application that people (not programmers) actually use, you need a UI.

To resolve this issue, I just hauled a reference to the original UI from the Client through the interface, through the proxy and on to the real subject. This was done through a parameter that held the login information checked by the proxy object which could be passed from the proxy to the real subject where the text file data are loaded.

Gil’s solution is to use an event handler class for the loaded data (DataLoadedEvent) and one for errors (DataLoadedErrorEvent). Event listeners were added to the proxy instance (of SubProxy) so that when an event is fired it can capture the returns from it. In order for this to work with the RealSubject, the abstract class that replaced the interface had to extend the EventDispatcher class. Because both the RealSubject and SubProxy are extended from the AbsSubject (abstract subject), they both inherit EventDispatcher properties and methods.

The tricky part comes where the dispatched event comes back to the client. Remember that the proxy class has the event listener and not the real class where the data are loaded. So how is the proxy class instance going to “hear” the event dispatched from the real subject? Well, remember the cardinal rule of design patterns?

Program to an interface and not an implementation.

In the client, Gil typed the SubProxy instance to the interface–the abstract class (which is an interface in the broader sense); so it catches events of the interface’s child classes. That’s possible because the interface is an extension of the EventDispatcher class.

Lest We Devolve into a Discussion of Algorithms….

Generally on this blog, I avoid discussions (and quibbles more so) about algorithms. However, I did bring up the discussion of Skip Lists and a few other places where we can knock around algorithms instead of relationships between participants in a design pattern. However, I believe that event dispatching and event handlers are part of the communication between the objects that make up design patterns, and so I welcomed Gil’s revision of the Protection Proxy. If others would like to join in this discussion of how to best communicate between the classes in the Proxy (or design patterns in general) dispatching messages using event dispatchers or other techniques, I believe it would be useful.

This is not a bugle call for reeling out some warmed over algorithms and telling everyone why they’re your favorite, but rather one for inter-object communication in ActionScript 3.0 design patterns. I think there’s some fertile soil here and one that would be fun to explore.

Gil’s Solution

The classes that make up Gil’s solution are equally appropriate for Flash or Flex, and while the downloaded files have a Flash CS5 FLA file, just about any version of Flash or Flex (Flash Builder) can be used. They are presented here with minimum discussion.

Helper Classes

First, Gil’s two helper classes extend the Event class.

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

package
{
	import flash.events.Event;
 
	public class DataLoadedEvent extends Event
	{
		private var m_dataStr:String;
		public static const DATA_LOADED_EVENT:String="DATA_LOADED_EVENT";
 
		public function DataLoadedEvent(type:String,dataStrParam:String,bubbles:Boolean=false,cancelable:Boolean=false)
		{
			this.dataStr=dataStrParam;
			super(type,bubbles,cancelable);
		}
 
		public function set dataStr(value:String):void
		{
			m_dataStr=value;
		}
 
		public function get dataStr():String
		{
			return m_dataStr;
		}
 
		override public function clone():Event
		{
			return new DataLoadedEvent(type,dataStr);
		}
	}
}

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

package
{
	import flash.events.Event;
 
	public class DataLoadedErrorEvent extends Event
	{
		private var m_errorStr:String;
		public static const DATA_LOADED_ERROR_EVENT:String="DATA_LOADED_ERROR_EVENT";
 
		public function DataLoadedErrorEvent(type:String,errorStrParam:String,bubbles:Boolean=false,cancelable:Boolean=false)
		{
			this.errorStr=errorStrParam;
			super(type,bubbles,cancelable);
		}
 
		public function set errorStr(value:String):void
		{
			m_errorStr=value;
		}
 
		public function get errorStr():String
		{
			return m_errorStr;
		}
 
		override public function clone():Event
		{
			return new DataLoadedErrorEvent(type,errorStr);
		}
	}
}

I really liked the way that Gil used static constants to set up a string property for dispatch. Also, note the parameters used in the DataLoaded and DataLoadedError events. The super() reference is to the Event class.

The Client

The Client class is pretty busy making requests and setting up event listeners and returning data for the UI.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90

package
{
	import fl.controls.Button;
	import fl.controls.Label;
	import fl.controls.TextArea;
	import fl.controls.TextInput;
 
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.events.MouseEvent;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
	import flash.text.TextFormat;
 
	public class Client extends Sprite
	{
		private var proxy:AbsSubject;
		private var lblUN:Label=new Label  ;
		private var lblPW:Label=new Label  ;
		private var txt:TextField=new TextField  ;
		private var format:TextFormat=new TextFormat  ;
		private var txtArea:TextArea=new TextArea  ;
		private var userInput:TextInput=new TextInput  ;
		private var pwInput:TextInput=new TextInput  ;
		private var btn:Button=new Button  ;
 
		public function Client()
		{
			setText();
			setIO();
			btn.addEventListener(MouseEvent.CLICK,requestTextVars);
		}
 
		private function setText()
		{
			format.font="Arial Black";
			format.size=24;
			format.color="0x990000";
			txt.defaultTextFormat=format;
			addChild(txt);
			txt.autoSize=TextFieldAutoSize.LEFT;
			txt.text="Protected Proxy";
			txt.x=32,txt.y=8;
			txt.height=24;
			lblUN.text="User name";
			lblUN.x=36,lblUN.y=48;
			addChild(lblUN);
			lblPW.text="Password";
			lblPW.x=36,lblPW.y=72;
			addChild(lblPW);
			btn.x=220,btn.y=72;
			btn.label="Show Data";
			btn.width=80;
			addChild(btn);
		}
		private function setIO()
		{
			addChild(userInput);
			userInput.x=100,userInput.y=48;
			userInput.text="Bill";
			addChild(pwInput);
			pwInput.displayAsPassword=true;
			pwInput.x=100,pwInput.y=72;
			pwInput.text="as3";
 
			addChild(txtArea);
			txtArea.width=248;
			txtArea.height=250;
			txtArea.x=32,txtArea.y=104;
		}
 
		private function requestTextVars(e:MouseEvent)
		{
			proxy=new SubProxy  ;
			proxy.addEventListener(DataLoadedEvent.DATA_LOADED_EVENT,onDataLoaded);
			proxy.addEventListener(DataLoadedErrorEvent.DATA_LOADED_ERROR_EVENT,onDataLoadedError);
			proxy.pxRequest(userInput.text,pwInput.text);
		}
 
		private function onDataLoaded(e:DataLoadedEvent):void
		{
			txtArea.text=e.dataStr;
		}
 
		private function onDataLoadedError(e:DataLoadedErrorEvent):void
		{
			txtArea.text=e.errorStr;
		}
	}
}

You might notice that the client looks a lot like the original, and that is very valuable. In this way, you can better compare how each deals with the information that is passed back to the UI in the client—either as an error or data.

The Main Classes

This is a golden opportunity for me to start a rant about those who call their Client classes Main, but I won’t until I have more time to waste. However, when thinking Main, you should be thinking about the classes that make up the main part of the design pattern and not the Client who is making requests from the main structure of the program. (Yeah, I know, even the Gang of Four have classes called Main that are really clients.)

Gil included a constructor class in the AbsSubject. I took it out for two reasons. First, it’s an abstract class that you’d never instantiate. Second, it detracts from the key methods and properties in the class. If someone can tell me when you’d ever need a constructor class in an abstract class, let me know. (I mean a good reason.)

1
2
3
4
5
6
7
8
9
10
11
12

package
{
	import flash.events.EventDispatcher;
 
	public class AbsSubject extends EventDispatcher
	{
		public function pxRequest(userName:String,password:String):void
		{
			// override
		}
	}
}

The Proxy Class

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
41

package
{
	import flash.events.EventDispatcher;
 
	public class SubProxy extends AbsSubject
	{
		private var m_realSub:AbsSubject;
		private var m_userName:String;
		private var m_password:String;
 
		override public function pxRequest(userName:String, password:String):void
		{
			if (userName=="Bill"&&password=="as3")
			{
				m_userName=userName;
				m_password=password;
				m_realSub = new RealSubject();
				m_realSub.addEventListener(DataLoadedEvent.DATA_LOADED_EVENT, onDataLoaded);
				m_realSub.addEventListener(DataLoadedErrorEvent.DATA_LOADED_ERROR_EVENT, onDataLoadedError);
				m_realSub.pxRequest(m_userName, m_password);
			}
			else
			{
				// PROTECTION errors are dispatched from the protection proxy (ONLY error events)
				dispatchEvent(new DataLoadedErrorEvent(DataLoadedErrorEvent.DATA_LOADED_ERROR_EVENT, "Adios..."));
			}
		}
 
		private function onDataLoaded(e:DataLoadedEvent):void
		{
			// resend (clone) the events from the realSubject to the proxy's listenners
			dispatchEvent(e);
		}
 
		private function onDataLoadedError(e:DataLoadedErrorEvent):void
		{
			// resend (clone) the events from the realSubject to the proxy's listenners
			dispatchEvent(e);
		}
	}
}

The Real Subject

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54

package
{
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.net.URLLoader;
	import flash.net.URLRequest;
	import flash.net.URLRequestMethod;
	import flash.net.URLVariables;
 
	public class RealSubject extends AbsSubject
	{
		private var urlString:String="fromText.txt";
		private var dataNow:URLVariables;
		private var txtLoader:URLLoader = new URLLoader();
		private var requestNow:URLRequest=new URLRequest(urlString);
 
		override public function pxRequest(userName:String, password:String):void
		{
			requestNow.method=URLRequestMethod.POST;
			txtLoader.addEventListener( Event.COMPLETE, loadTXT );
			try
			{
				txtLoader.load( requestNow );
			}
			catch (e:ArgumentError)
			{
				// INTERNAL errors are dispatched from the subject too
				dispatchEvent(new DataLoadedErrorEvent(DataLoadedErrorEvent.DATA_LOADED_ERROR_EVENT, e.toString()));
			}
			catch (e:SecurityError)
			{
				// INTERNAL errors are dispatched from the subject too
				dispatchEvent(new DataLoadedErrorEvent(DataLoadedErrorEvent.DATA_LOADED_ERROR_EVENT, e.toString()));
			}
		}
 
		private function loadTXT( e:Event ):void
		{
			txtLoader.removeEventListener( Event.COMPLETE, loadTXT );
			dataNow=new URLVariables(txtLoader.data);
			var resultStr:String=dataNow.record1;
			resultStr+=dataNow.record2;
			resultStr+=dataNow.record3;
			resultStr+=dataNow.record4;
			resultStr+=dataNow.record5;
			resultStr+=dataNow.record6;
			resultStr+=dataNow.record7;
			resultStr+=dataNow.record8;
 
			// success are sent from the actual subjects (NOT only success events)
			dispatchEvent(new DataLoadedEvent(DataLoadedEvent.DATA_LOADED_EVENT, resultStr));
		}
	}
}

I want to thank Gil for this and he gets 4 World Cup points for adding this to our discussion of ActionScript 3.0 Design patterns.

FCNY Meeting

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.)

Figure 1: Stratified Protection Proxy

Let the Proxy Do the Work

A Proxy design pattern has many different functions, but one of the most important is to handle all of the filtering work from the requested object. The hypothetical situation in the example is one where different people have different levels of access to data. In order to determine the level of access, the Proxy (SubProxy) object does all of the deciding work instead of passing it to the individual objects that contain the actual operations requested by the Client. In this way, you keep out duplicate code (filtering work) and you protect the RealSubject participants from unwarranted access. As you can see in the following Proxy class, it both protects and filters in a single operation:

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
41
42
43

package
{
	import fl.controls.TextArea;
 
	public class SubProxy implements ISubject
	{
		//Declare as interface data type
		private var realSub:ISubject;
 
		private var txtArea:TextArea;
		private var un:String;
		private var pw:String;
 
		public function pxRequest(tx:TextArea,un:String,pw:String):void
		{
			this.un=un;
			this.pw=pw;
			txtArea=tx;
                        //Access to international data
			if (this.un=="Lisa" && this.pw=="fms4")
			{
				realSub=new International();
				realSub.pxRequest(txtArea,null,null);
			}
                        //Access to national data
			else if (this.un=="Tyler" && this.pw=="dp")
			{
				realSub=new National();
				realSub.pxRequest(txtArea,null,null);
			}
                        //Access to local data
			else if (this.un=="Will" && this.pw=="flex")
			{
				realSub=new Local();
				realSub.pxRequest(txtArea,null,null);
			}
			else
			{
				txtArea.text="Adios...";
			}
		}
	}
}

Also notice that the realSub object is typed as the ISubject interface. As a result, the conditional options can use the same object name to instantiate the requested object while simultaneously filtering access. Also, the exact same request is forwarded using the identical call because all of the RealSubject participants implement the same interface (as does the Proxy).

Real World Protection Proxy

When I started preparing materials for the FCNY presentation, I was planning on setting one up with different access to a MySQL database using PHP. However, I got jammed up with editorial and writing tasks that I could not put off. Nevertheless, if you have the time (and inclination) you can make some modifications to this example and change each of the RealSubject classes to different database access such as, read data, add data, change data and even delete data. Anyone working on a dating site isn’t going to let all of its members have unlimited access; instead you have access depending on your role. Likewise, the Protection Proxy can protect and filter access to objects of virtually any kind. So the next time you have to deal with this kind of issue, consider using the Proxy.

I’d be remiss if I didn’t thank Will Saunders (my long lost son) for setting up the visit to NYC, and I do. It was fun meeting all of the FCNY members, and I encourage any of you Flash developers who live in the NYC area to pay them a visit. If you enjoy their meeting half as much as I did, you’ll have a great time.

Proxy and Real Subject

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:

Figure 1: Proxy class diagram

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:

Figure 2: Proxy object diagram

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.

GoF list three uses of indirection:

1. A remote proxy can hide the fact that an object resides in a different address space.
2. A virtual proxy can perform optimizations such as creating an object on demand.
3. Both protection proxies and smart references allow additional housekeeping when the object is accessed.

Since we’re looking at the Protection proxy, we need to consider what additional housekeeping may entail.

Begin with the premise that a key function of the Proxy pattern is to prevent unnecessary creation of an object—especially a large, expensive one. Imagine a Web site that does not use a proxy but first creates an object with every request and then decides whether or not the request is valid. Thousands of requests along with the creation of the object could possibly slow operations to a crawl and none of the requests would result in using the object. With a Proxy, none of the blocked requests would create an object in the first place because the Proxy would handle the request.

Once the Proxy decides that the request will be allowed, it can handle any number of other chores. We discussed different access rights above when considering a dating site. Why should the requested object have to deal with access rights when the Proxy could do it instead? No reason at all. For this first post on the Protection Proxy, we will only look at handling a single chore—access. However, we should consider how the design pattern might be important for dealing with options.

Loose Coupling and RealSubject Options

One way to look at the Protection Proxy as a way to maintain loose coupling is to consider the flexibility one has in using, changing and adding RealSubject participants. If the Proxy and RealSubject share an interface the same set of parameters and methods can be used for both. Further, having more than one RealSubject is possible because the additional housekeeping is handled by the Proxy. Instead of having a single RealSubject responsible for different levels of access, the Proxy can determine the level of access and call the appropriate RealSubject for any level of access. As a result, the RealSubjects can be only large enough to handle what the access level requires. For example, if one is designing an application where access is to a database object, the object may have the following options:

• Access to data only
• Access to data and adding data
• Access to data, adding data and changing data
• Access to data, adding data, changing data and deleting records

Rather than have the program create a single large complex object for every access, a more efficient design would be to create different RealSubjects depending on level of access. So if most users only have access to read data, the program does not have to create a large complex object that reads, adds, changes and deletes data. At the same time the design can handle all the other levels of access by calling the appropriate RealSubject; it just doesn’t have to invoke them where they’re not required.

So in terms of design patterns, I believe that the Proxy should be considered beyond the basic indirection it provides. As long as the Proxy is handling the access details, the developer does not have to worry about access coding when developing the RealSubjects. Further, he can add, change and remove RealSubjects as needed without disturbing the entire program.

Accessing Text Data using a Name/Value Pair

To start with a simple example, this Protection Proxy monitors requests to open and read a text file. The text file represents any external data, and virtually the same code can be used to read a database. So, treat it as a generic database instead of a text file, and in Part 2, we’ll use a real MySQL database that is called via a PHP program. However, to kick things off, you don’t need a database or PHP—all you need is ActionScript 3.0 and a text file.

The name/value pair is a common data representation. As used with ActionScript 3.0 and external data, each name/value pair is separated by an ampersand (&) in the loaded data stream. For example, suppose we we want to have three variables representing name, city and country, the data stream would be organized as follows:

name=Nelson Mandela&city=Johannesburg&country=South Africa

The variables are accessed as properties of the loaded object. In this case the object is a URLVariable, and to access it use the following code where NCC is the URLVariable instance:

display.txt=NCC.name;
display.txt +=NCC.city;
display.txt +=NCC.country;

In order to better simulate a database table, the variables (name) will be given the name record followed by a number. Open a text editor (Notepad or TextEdit will work fine) and enter the following:

1
2
3
4
5
6
7
8

record1=001 Fred Smith  programmer  ActionScript 3.0
&record2=002 Hanna Brauer programmer JavaScript
&record3=003 Aalok Gupta designer  Adobe Illustrator
&record4=004 Anna Petrov  designer  Adobe Photoshop
&record5=005 Iracema Galleti programmer ActionScript 3.0
&record6=006 Roberto Gonzalez programmer PHP
&record7=007 Abeeku Badu programmer Java
&record8=008 Fang Yin Zhao designer Adobe Illustrator

Save the text file as fromText.txt. Place the file in the same directory as the other ActionScript 3.0 files you will create for the Protection Proxy.

The Subject and its Children

The Subject participant is some kind of interface—either an interface or abstract class. For this project, I used an interface named ISubject. It has a single abstract method, pxRequest(). (Were request not a built-in method in ActionScript 3.0, I would have used that name.)

1
2
3
4
5
6
7
8

package
{
	import fl.controls.TextArea;
	interface ISubject
	{
		function pxRequest(tx:TextArea,un:String,pw:String):void;
	}
}

As far as interfaces go, ISubject is a bit more busy than most. It only has a single method, but that method has three parameters and the interface had to import a TextArea control. The reference to the TextArea is to “carry back” the reference to the Client request. However, because I was unable to find a way to return the contents of the text file, I carried the output control all the way to the RealSubject. The user name and password made up the two string parameters.

The Proxy Class

I named the Proxy class SubProxy (for Subject Proxy) because Proxy is a reserved word (for an ActionScript 3.0 class.) In this implementation, the SubProxy class simply checks to see if the username and password or acceptable, and if so, it calls the RealSubject. Otherwise it dismisses the request.

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

package
{
	import fl.controls.TextArea;
 
	public class SubProxy implements ISubject
	{
		private var realSub:ISubject;
		private var txtArea:TextArea;
		private var un:String;
		private var pw:String;
 
		public function pxRequest(tx:TextArea,un:String,pw:String):void
		{
			this.un=un;
			this.pw=pw;
			txtArea=tx;
			if (this.un=="Bill" && this.pw=="as3")
			{
				realSub=new RealSubject();
				realSub.pxRequest(txtArea,null,null);
			}
			else
			{
				txtArea.text="Adios...";
			}
		}
	}
}

An important feature to note is in the SubProxy class is the RealSubject request (realSub.pxRequest(txtArea,null,null);). The second two parameters requesting strings for a username and password are set to null. The null primary expression keyword is not a typed object and works well for filling empty parameters were required by the interface. In this case I wanted to bring it to your attention to emphasize that all housekeeping chores are handled by the SubProxy class. In Part II, you will see far more work by the Proxy, but the RealSubject only does what it’s requested to do—which does not include housekeeping.

The RealSubject Class

Think of the RealSubject participant in the Protection Proxy design pattern as any useful object. In this case, the useful object is one that returns data from a text file. It does so by taking the data from the text file and putting it into a TextArea object.

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
41
42
43
44
45
46
47
48
49
50
51

package
{
	import flash.net.URLRequest;
	import flash.net.URLVariables;
	import flash.net.URLLoader;
	import flash.net.URLRequestMethod;
	import flash.events.Event;
	import fl.controls.TextArea;
 
	public class RealSubject implements ISubject
	{
		private var urlString:String="fromText.txt";
		private var dataNow:URLVariables;
		private var txtLoader:URLLoader = new URLLoader();
		private var requestNow:URLRequest=new URLRequest(urlString);
		private var tx:TextArea;
 
		public function pxRequest(tx:TextArea,un:String,pw:String):void
		{
			this.tx=tx;
			requestNow.method=URLRequestMethod.POST;
			txtLoader.addEventListener( Event.COMPLETE, loadTXT );
			try
			{
				txtLoader.load( requestNow );
			}
			catch (e:ArgumentError)
			{
				this.tx.text=e;
			}
			catch (e:SecurityError)
			{
				this.tx.text=e;
			}
		}
 
		private function loadTXT( e:Event ):void
		{
			txtLoader.removeEventListener( Event.COMPLETE, loadTXT );
			dataNow=new URLVariables(txtLoader.data);
			tx.text=dataNow.record1;
			tx.appendText(dataNow.record2);
			tx.appendText(dataNow.record3);
			tx.appendText(dataNow.record4);
			tx.appendText(dataNow.record5);
			tx.appendText(dataNow.record6);
			tx.appendText(dataNow.record7);
			tx.appendText(dataNow.record8);
		}
	}
}

The difficulty I had with this program was trying to return the data. The original request relies on an event (COMPLETE) to set the stage for using the data. Prior to that event, nothing can be returned, and the event handler cannot be called directly. Using a trace statement works fine, but beyond debugging it’s useless. I could find no way to use the TextArea component beyond the Client without passing it along as a parameter. (Apparently, no one else could either from searching the Web. However, if you have a way to return data from the RealSubject using a return statement—please send it in with working code.) Anyway, as you have seen, this technique works perfectly well.

The Client

All the Client does (even though it is the largest of the classes) is to provide a place to enter a username and password and request the data.

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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

package
{
	import flash.display.Sprite;
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.text.TextFieldAutoSize;
	import fl.controls.Label;
	import fl.controls.TextArea;
	import fl.controls.Button;
	import fl.controls.TextInput;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var proxy:ISubject;
		private var lblUN:Label=new Label();
		private var lblPW:Label=new Label();
		private var txt:TextField=new TextField;
		private var format:TextFormat=new TextFormat;
		private var txtArea:TextArea=new TextArea();
		private var userInput:TextInput=new TextInput();
		private var pwInput:TextInput=new TextInput();
		private var btn:Button = new Button();
 
		public function Client()
		{
			setText();
			setIO();
			btn.addEventListener(MouseEvent.CLICK, requestTextVars);
		}
 
		private function setText()
		{
			format.font="Arial Black";
			format.size=24;
			format.color="0x990000";
			txt.defaultTextFormat=format;
			addChild(txt);
			txt.autoSize=TextFieldAutoSize.LEFT;
			txt.text="Protected Proxy";
			txt.x=32,txt.y=8;
			txt.height=24;
			lblUN.text="User name";
			lblUN.x=136,lblUN.y=48;
			addChild(lblUN);
			lblPW.text="Password";
			lblPW.x=136,lblPW.y=72;
			addChild(lblPW);
			btn.x=200, btn.y=72;
			btn.label= "Show Data";
			btn.width=80;
			addChild(btn);
		}
		private function setIO()
		{
			addChild(userInput);
			userInput.x=32,userInput.y=48;
			addChild(pwInput);
			pwInput.displayAsPassword=true;
			pwInput.x=32,pwInput.y=72;
			addChild(txtArea);
			txtArea.width=248;
			txtArea.height=250;
			txtArea.x=32,txtArea.y=104;
		}
		private function requestTextVars(e:MouseEvent)
		{
			proxy=new SubProxy();
			proxy.pxRequest(txtArea,userInput.text,pwInput.text);
		}
	}
}

Using the requestTextVars()method with literals, the whole thing could have been done with three lines, but to be realistic, the Client needs to have user entry—username and password. The TextArea is automatically supplied; so the user simply types in the username and password and clicks the button to request the data. (Little does she know that the request is re-directed to the Proxy.)

No Constructor Functions, Please

You may have noticed that no constructor functions were used in any of the participants. I’ve started leaving out constructor functions unless they have something to do—as is the case with the Client. I have noted in several previous posts that the Google programming standards bearer, Miško Hevery, cautions that constructor functions should do no real work. Here’s why:

When your constructor has to instantiate and initialize its collaborators, the result tends to be an inflexible and prematurely coupled design.

One way to help remember that is not to put them in the participant classes. True, constructor functions are automatically generated if none is placed in a class; however, by leaving out explicit constructor functions I’m not tempted to give them any real work.

In Part II, we’re going to give the Proxy a real workout and several options. Also, instead of a single RealSubject, there will be several. This means that the Proxy is going to have to filter through different levels of access and then select which will be appropriate for the request.

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.

A Login Example

The login example stemmed from my experiences with Blackboard. The ease with which I am able to “re-log” without having to wait for a total reload is the driving rationale behind this abstract, virtual proxy design pattern. It is simple, yet informative both as an example of good OOP and design patterns.

To get started, I put together a class diagram with the classes I planned to use reflecting the Proxy design pattern as shown in Figure 3:

Figure 3

The client instantiates a ProxyLogin typed as ISecurity, the interface. The proxy instance checks the username to see if the user is logged in; if so, it executes the login method that indicates that the user is already logged in. Otherwise, the proxy instantiates an instance of the RealLogin class, and it loads everything that needs loading and then informs the user that the login has been successful.

The Subject Interface, Proxy and Real Deal

First, the Subject class is an interface, ISecurity. It has a single method as the first listing shows:

1
2
3
4
5
6
7

package
{
	public interface ISecurity
	{
		function login():void;
	}
}

Next, the Proxy class, LoginProxy, checks to see if the user is logged in. by checking the object containing login information:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

package
{
public class ProxyLogin implements ISecurity
	{
		private var username:String;
		private var loggedIn:ISecurity;
 
		public function ProxyLogin(username:String)
		{
			this.username=username;
		}
		public function login():void
		{
			if (loggedIn==null)
			{
				loggedIn=new RealLogin(username);
			}
			loggedIn.login();
		}
	}
}

Now, the proxy will use a RealLogin object and its operations only if it finds that no object with the username has logged in. It instantiates a new instance of RealLogin() with the username as a parameter. So let’s see what happens next:

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

package
{
	public class RealLogin implements ISecurity
	{
		private var username:String;
 
		public function RealLogin(username:String)
		{
			this.username=username;
			doLogin();
		}
 
		private function doLogin():void
		{
			trace("Connect "+username+" to server");
			trace("Check "+username+"'s credentials");
			trace("Load data from database for "+username);
			trace("Compare "+username+"'s IP with banned list");
			trace("Verify "+username+"'s security level \n");
		}
 
		public function login():void
		{
			trace(username + " has logged in.\n");
		}
	}
}

All of trace() statements in the doLogin() method represent heavy lifting by the application. The whole point is to avoid the doLogin() method if at all possible by re-using an existing login through the Proxy participant. After each login, the login() method indicates who has logged in.

The Client

The client requests a login by instantiating a ProxyLogin object. Then each object makes a request through the login() method. Because none have logged in initially, the ProxyLogin must invoke the RealLogin . To simulate re-logging in after a user is currently logged in, the client (SecurityProxy), one of the users (steve) logs in multiple times. However, as you will see, after the first login, repeat logins are free in that the materials generated initially no longer require the RealLogin.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package
{
	import flash.display.Sprite;
 
	public class SecurityProxy extends Sprite
	{
		private var bill:ISecurity;
		private var steve:ISecurity;
		private var stephen:ISecurity;
 
		public function SecurityProxy()
		{
			bill=new ProxyLogin("Gates");
			steve=new ProxyLogin("Jobs");
			stephen=new ProxyLogin("Hawking");
 
			bill.login();
			steve.login();
			steve.login();
			stephen.login();
			steve.login();
		}
	}
}

Note where the \n is placed to force an additional linefeed. That’s to separate the login announcement from all of the chores required to login. When all you see is repeated login announcement without all of the trace statements, it indicates that the user has re-logged. The following output is generated by the client’s request:

Connect Gates to server
Check Gates's credentials
Load data from database for Gates
Compare Gates's IP with banned list
Verify Gates's security level

Jobs has logged in.

Note that instances bill (“Gates”) and stephen (“Hawking”) log in only once. However, steve (“Jobs”) logs in two additional times after an initial login. The logins after the initial ones show the value of the virtual proxy design. All of the other tasks for login are not repeated, but instead the user is logged in without additional work by the RealLogin object.