ActionScript 3.0 Design Patterns

It's Time for Your Dependency Injection!

The go-to guy in dependency injection is Martin Fowler, but I first became aware of it in one of Miško Hevery’s posts, and it was the topic of his discussion at last year’s OOPSLA meetings in Orlando, Florida. In looking around for different takes on dependency injection (or DI as all the cool kids call it), one of the better ones was by Griffin Caprio on an MSDN page. Caprio uses a Factory example, but alas, it’s an Abstract Factory, and I get the heebie-jeebies just looking at the class diagram. So explaining DI using an Abstract Factory is like explaining simple arithmetic using quantum physics. (Just clench your teeth and click the link to get the rest.)

The Just-Right Explanation

I suppose it takes no small amount of cheek to claim one’s own explanation is the right one, but since that seems what everyone else is doing, I don’t want to rock the boat. (The exception is Wikipedia that doesn’t understand its own explanation and says so!) In part, the problem stems from the fact and a lot of dependency injection is handled by frameworks like Guice, PicoContainer and Spring. Then the discussion quickly turns either to a discussion of which framework to use (or even why to avoid one) and why dependency injection is (generally) a good thing. (Of course that discussion is carried out assuming that you fully understand what the framework is doing and all the 1,352 libraries in Java.)

According to Martin Fowler, who with others coined the term, Dependency Injection, we have three kinds of DI—all of which are a sub-type of inversion of control (IoC). They are:

• Type 1 IoC (interface injection)
• Type 2 IoC (setter injection)
• Type 3 IoC (constructor injection)

For this post, I’ll focus on only one type—Type 3, Constructor injection, and I’ll generate an example in ActionScript 3.0. Besides, I’m only going to focus on a single aspect of DI and try and keep things at a general enough level for everything to be kept in perspective. Further, I’ll not build a DI framework or recommend one. This post is one just to introduce the DI concept in the hopes of generating some discussion.

It All Starts with the Component and Service

Following Fowler’s lead, I’d like to begin with a request for a service from a component. Both the Component and Service are chunks of software (possibly classes) where one is dependent on the other for some kind of service. Fowler had a model in mind that reminded me of an ActionScript 3.0 application making a database request via PHP. In this case the PHP is the foreign application that provides the service to the AS3 component.

In the context of design patterns, we can easily imagine one class using another class for services it does not offer itself. Indeed, the whole idea of DI appears to be hard-wired in many of the patterns we’ve discussed. Further, the Hollywood Principle is an inversion of control concept and DI is a type of inversion of control; so much of what we’ll discuss is not new to those familiar with design patterns.

Why Dependency Injection? Martin Fowler wanted to explore an ongoing issue in programming—how to wire different components together. One common answer to the issue of connecting objects from different projects is Inversion of Control (IoC), and Dependency Injection (DI) represents a specific type of IoC. However, I also see it as the right step in reducing service class overhead as well. (Getting the mother-in-law with the spouse when all you want is just the spouse. )

What is Dependency Injecting? Generally, the discussions about DI include a review of the framework[s] that support a particular DI do, but dependency injection itself is about placing an object (service) needed by a component into the component. The component depends on the service for a certain functionality, and it is injected into the component. Type 3 IoC (constructor injection) is done by injecting the service into the component’s constructor. The following classes illustrate this using 1) a client class, 2) a component class, and 3) a service class.

The first step is to set up the Component class as “injectable” by providing the constructor class with a service parameter. This parameter is the service that the Component depends on. Then we’ll provide some operations (methods) that use the service in the Component.

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 Component extends Sprite
	{
		private var service:IService;
 
		public function Component(otherService:IService)
		{
			service=otherService;
		}
 
		public function doPlant():void
		{
			service.plant();
		}
 
		public function doHarvest():void
		{
			service.harvest();
		}
	}
}

Next, the service interface provides two methods. The methods were opposites but related, plant and harvest, and so they probably would not be needed at the same time. (This stems from reading too much Miško Hevery who cautions against unwittingly leaving a whole class to be instantiated when you only need some of its operations.) Anyway, the Service class simply implements the IService interface. Both the interface and class follow:

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

//Interface
package
{
	public interface IService
	{
		function plant():void;
		function harvest():void;
	}
}
 
//Service
package
{
	public class Service implements IService
	{
		public function plant():void
		{
			trace("Plant the seeds or seedlings.");
		}
 
		public function harvest():void
		{
			trace("Mow and harvest the wheat.");
		}
	}
}

Given the arrangement of the Component class, it can now inject the Service into an instance of the Component. Here, we’ll use a simple Client to do so:

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

package
{
	import flash.display.Sprite;
	public class Client extends Sprite
	{
		private var otherService:IService=new Service();
		private var useServiceThroughComponent:Component;
		public function Client()
		{
			//->otherService<- is dependency injected in following line
			useServiceThroughComponent=new Component(otherService);
			useServiceThroughComponent.doPlant();
			//Or you can use the other functionality;
			//useServiceThroughComponent.doHarvest();
		}
	}
}

The purpose of DI is to maintain loose coupling between the Component and Service. The service becomes the one injected into the component in the Client. Further, it is typed as the service interface, and so there’s minimal coupling with a concrete class (actual service). However, as you can see in the example, you have full use of the services. The Component has no idea of what’s involved in the details of the service it has requested because it is through the interface and any changes to the service would not affect either the component or service. Further, the dependencies are injected through a constructor parameter.

Is a DI Framework Necessary for AS3 Design Patterns?

I’d feel a lot more comfortable about DIs if I knew more about DI frameworks. I know of none that have been implemented in and for AS3, but this may be something worth considering when using AS3 with PHP or ASP.NET/C#. However, I suspect we’d be better served by having design patterns guide both AS3 designs and PHP designs and then see if PHP services (e.g., database work) could smoothly be integrated and loosely incorporated by AS3.

I’d need to look at DI frameworks far more closely before making up my mind, but inversion of control is already hard-wired in so many patterns, that I’m not at all sure that DIs would not be redundant. I could be wrong about that, but inversion of control (IoC) is built into many patterns already. However, I wouldn’t mind being proven wrong, and I welcome comments.

Related posts:

1. Design Pattern Principles for ActionScript 3.0: The Dependency Inversion Principle