¡Agradecimentos outra vez para seus comentários!

Cordialmente,
Bill

Best Regards,
Henrique

You English is much better than my French, Spanish or Portuguese–or whatever language it is. No apologies necessary.

The Freemans (Head First) used abstract examples (system.out.println) with their ducks’ quacking and flying behaviors and so they didn’t have to dip into a library to pull out something that would provide a concrete operation. Basically, if I had used trace() I would not have had to extend Sprite. The Duck class is first a concrete Context and then an Abstract Context and the different types of Ducks (real, rubber, decoy) are subclasses of the Context class. The different behaviors are all separate Strategy interfaces (one for quacking and one for flying) and the implementations of those two strategies are used by different types of ducks.

Figure 1 (in the article) is what the Gang of Four used in their book, and while I only used a single strategy implementation of a strategy and had no child class for the Context, I didn’t need it. However, as you and others have demonstrated, it’s not too difficult to add more concrete strategies.

As for “family of algorithms” providing different loading algorithms certainly falls within a “family.” (GoF are pretty vague about what they mean about “family”, but I do believe that the Freemans “flying” and “quacking” are as good as any.) By the same token, so is “loading.”

In your example, Context class seems to be abstract, but in the original GoF class diagram, Context is concrete (one of the few places where you’ll find a concrete class that is subclassed in their book), but the Duck class the Freemans use is also abstract as well (the second one on pg. 18). However, I followed the Gang of Four’s class diagram and used a concrete Context class.(Their example also used a concrete Context participant.) Here’s what you need in the Context:

-configuration with a ConcreteStrategy object.
-maintains a reference to a Strategy object.

As you can see, those requirements are met. In addition you may:

- define an interface that lets Strategy access its (the Context’s) data.

I chose not to do that because I had no reason to do so. However, look how easy it is to add another concrete Strategy to load something other than a SWF (or graphic) file. For example, adding a concrete text loading strategy implementing the ILoader (Strategy) — as Curro did in the first comment.

In any event, I want to thank you for your comments. They add a good deal to the discussion.

Kindest regards,
Bill

Really nice tutorial! Incredible site too, great resource for the subject of Design Patterns and good practices on actionscript.
[I'm NOT a english speaker... so if I sound wrong or arrogant... just say it! Ok?]

Well, I have some complains, questions and maybe suggestions.

I really don’t like the “extend Sprite” on model classes. I know that in flash (almost) everything translates to display objects. The Sprite object is quite heavy and slow (to add and remove from the display). I also agree with Jiri that PixLoader should not render itself, just load stuff (single responsibility). But I understand your point of view also. Anyway, that is just me complaining and mumbling around.

Interesting observations were made by Jiri and Curro.But my question is: is correct to place another public method or property in the strategy (getContext or whatever)? All the strategy patterns that I read on books and on the web uses just one method. Head First Design Patterns talks about “family of algorithms” (like sort algorithms, tax algoritms, loader algorithms, …). Therefore the strategy should have only the ‘load’ method and not the ‘getContainer’ or unload, ….. But again, I’m not sure about that, just saying what I read about it. Would be good to know different opinions.

Another important point to think, in this example, is how flash and actionscript handles loading (for simplicity, consider only Loader and URLLoader, just ignore the fancy stuff like web services, sockets, etc, at least for now). Loading in flash, like all of you know, uses the event mechanism. So if your designer wants to do some nice loading animations, you really need to take that into consideration. You NEED to support that event mechanism on your strategy!

All said…, let’s code!

Starts with a simple interface. Note that ‘load’ returns something.

1
2
3
4
5
6
7

package
{
	public interface ILoadMaster
	{
		function load(url:String):*;
	}
}

Now the concrete class.

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

package
{
	import flash.display.Loader;
	import flash.net.URLRequest;
 
	public final class PixLoader implements ILoadMaster
	{
		private var request:URLRequest;
		private var loader:Loader;
 
		public function load(url:String):*
		{
			request = new URLRequest(url);
			loader = new Loader();
			loader.load(request);
 
			return loader;
		}
 
	}
}

And the other.

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

package
{
	import flash.net.URLLoader;
	import flash.net.URLRequest;
 
	public final class TextLoader implements ILoadMaster
	{
		private var request:URLRequest;
		private var loader:URLLoader;
 
		public function load(url:String):*
		{
			request = new URLRequest(url);
			loader = new URLLoader();
			loader.load(request);
 
			return loader;
		}
 
	}
}

The contexts…

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

package
{
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	public class Context extends Sprite
	{
		protected var loadMaster:ILoadMaster;
 
		public function Context(loadMaster:ILoadMaster)
		{
			this.loadMaster = loadMaster;
		}
 
		public function load(url:String):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
	}
}
 
 
 
package
{
	public final class PixContext extends Context
	{
		public function PixContext(loadMaster:ILoadMaster)
		{
			super(loadMaster);
		}
 
		public override function load(url:String):void
		{
			addChild(super.loadMaster.load(url)); // Pay attention! addChild!!
		}
 
	}
}
 
 
 
package
{
	public final class TextContext extends Context
	{
		public function TextContext(loadMaster:ILoadMaster)
		{
			super(loadMaster);
		}
 
		public override function load(url:String):void
		{
			super.loadMaster.load(url);
		}
 
	}
}

As you are returning Loader object from PixLoader and URLLoader from TextLoader you can add an event in the context class.

You could go further extending IEventDispatcher. Like so:

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 flash.events.IEventDispatcher;
 
	public interface ILoadMaster extends IEventDispatcher
	{
		function load(url:String):*;
	}
}
 
 
 
package
{
	import flash.display.Loader;
	import flash.events.Event;
	import flash.events.EventDispatcher;
	import flash.events.IEventDispatcher;
	import flash.net.URLRequest;
 
	public final class PixLoader extends EventDispatcher implements ILoadMaster
	{
		private var request:URLRequest;
		private var loader:Loader;
 
		public function load(url:String):*
		{
			request = new URLRequest(url);
			loader = new Loader();
			loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loaded);
			loader.load(request);
 
			return loader;
		}
 
		private function loaded(event:Event):void
		{
			//dispatchEvent(new Event(Event.COMPLETE));
			dispatchEvent(event);
		}
 
	}
}

Now you can directly dispatch events from your strategy. Not sure if its a good thing.

Polymorphism can be found in the Strategy classes themselves—they are written so that depending on the context of their use, they will have different meanings. I believe that we did type to the interface and not the implementation.

Kindest regards,
Bill

For example in the client…

protected var _context:IContext;

protected function init():void{
_context = new ConcreteContext(”someUrl.swf”);
}

Wow! You sure can pick the topics! Object pooling in design patterns is fairly controversial, but I agree it would be a good topic–just to see what the pros and cons are.

In some respects, we all want more speed, but with the speed of current memory and CPUs, it’s not the issue it once was with the old 8-bit processors and severely limited memory. Instead, the issue of speed has shifted to design and re-design. However, I’m a sucker for squeezing more speed from a program (as the Flyweight patterns does) and it is something that I think is worth a post. However, here’s a list of what I have to cover first:

Deal with my client’s project
Finish re-writing a video player
Posts on the following topics:
    Open/Closed Principle
    Dependency Inversion Principle
    Least Knowledge Principle
    Hollywood Principle
    One reason to change principle
    Part II of Builder Pattern

Possibly Chandima might be interested and we could have something sooner, but until I get these other projects off my desk, I can’t put anything new there. However, it is a perfect topic for this blog. (Maybe you’d like to write a post on it?)

Thanks for the great idea,
Bill

Jiri

In your code just type in the symbols as you always do. Your code was fine. I just added the <pre> tags to format it–never use the UTF-8 code in your programs.

A lot of developers (myself included) have used multiple Context classes–an abstract base class and multiple concrete implementations. However, I’ve been going the other way–towards a single concrete Context class.

I suppose either way works. Anyway, the question to ask with design patterns is, what will happen if I make changes? As long as you can keep the relations loose and functional, you will find many variations that you can work with.

Thanks for all your interest and very nice work.

Kindest regards,
Bill