Simon Wacker

Applications consist of multiple classes which collaborate with each other. For example an instance of class A needs an instance of class B and C to do its job; in other words, class A depends on class B and C; class B and C are thus dependencies of class A.

There are three options to satisfy dependencies:

1. hard-code dependencies,
2. look up dependencies,
3. use the Dependency Injection pattern.

1. Hard-coding dependencies is the easiest strategy: class A simply instantiates its dependencies.

Problems of hard-coding dependencies:

• Configuration is distributed across the whole application (configuration is in this case wiring up the instances and configuring dependent instances).
• Class A must be modified to exchange a dependency (tight coupling): the instance of B may be replaced by an instance of SubB which fulfils the same contract as its super-class B. If B were an interface than any implementations could be used to satisfy the dependency.
• What if a fourth class D has a dependency to the same instance of B as class A?

2. Looking up dependencies requires a context: class A gets the context and looks up its dependencies.

Advantages of looking up dependencies:

• Partially centralized configuration of the context: dependency b is already fully configured; but every instance looks up its dependencies on its own.
• One instance can be used to satisfy multiple dependencies: an instance of class D can simply use context.getB() to get the same instance.

Problems of looking up dependencies:

• Class A depends on a context: makes unit testing more difficult and the look ups are disturbing.
• Code is bloated with dependency look-ups.

3. Using the Dependency Injection pattern is simple and places no requirements: class A provides ways to inject dependencies.

Advantages of dependency injection:

• Configuration is centralized in one place: both configuration of instances and wiring up instances.
• Dependencies can be exchanged easily (loose coupling).
• Wiring up instances is made easy.

Problem of dependency injection: The wiring code may become rather complex if there are a lot of instances with a lot of dependencies to satisfy.

One way to go is to use Constructor Injection. In this approach class A declares a constructor with paramters for both dependencies; the dependencies are given on instantiation.

Advantages of constructor injection:

• Dependencies cannot be changed after instantiation.
• Initialization which requires all dependencies can be done directly in the constructor.
• Instance is not in illegal state after instantiation.

Problems of constructor injection:

• Parameter list of constructor may become very long (there may be a lot of dependencies, plus other information to pass to the constructor).
• Parameters are distinguished by index and not by name, which may make the code harder to understand.

Another way to go is Setter Injection. In this approach class A provides setters for both dependencies; the dependencies are satisfied after instantiation.

Advantages of setter injection:

• Constructor can be used to pass other information than dependencies.
• Code is easier to understand because names rather than indices are used to distinguish dependencies.

Problems of setter injection:

• Dependencies may not have been satisfied when needed.
• Dependencies may be changed after ‘official’ initialization.
• Initialization may have to be done after all dependencies are satisfied: init-method is needed.

While dependency injection is a pattern with many advantages, there are also some problems when used extensively, which can only be solved by an Inversion of Control Container. Such a container provides means of managing instances: lifecycle management (instantiating classes, setting dependencies, invoking init-methods, destroying classes), looking up managed instances, configuring managed instances, resolving dependencies.

In my following articles I’m going to present the As2lib Inversion of Control Container and show you how it solves the problems mentioned above and which other functionalities it provides (for example using its generic XML dialect to create UIs with ActionStep, AsWing, EnFlash or any other component library).

Further Reading: Inversion of Control Containers and the Dependency Injection pattern

A thread about the Singleton Design Pattern arised in the Flashforum (German). We (Nico Zimmermann, Ralf Bokelberg, Florian Kruesch and myself) discussed different implementations of the Singleton Pattern and what the advantages and disadvantages of each are. All started very basic with the simplest implementation all of you probably know.

Then we thought about the problems that emerge using this kind of implementation.
The first problem is that it is awkward to substitute the currently used Singleton with a new one. You had to change ALL references.
The second and maybe not that obvious issue is that only one instance of the Singleton class can exist in the whole project.
You probably think: Why should that be a problem? Doesn’t it lie in the nature of a Singleton that only one instance can exist of it?
These two statements are probably right BUT you normally want to have one instance of the Singleton in one context and not only one in a whole project. Thus my definition of a Singleton would be the following: A Singleton is a class that has exactly one instance in one context. This instance is shared among all classes in that context.
This definition sadly conflicts with the one of GoF (Gang of Four): Ensure a class only has one instance, and provide a global point of access to it.
But I think that the variation is acceptable. My definition maybe reminds you more of the Multiton Design Pattern.
So, how would one implement such a context spcific Singleton. That’s rather easy. You just have to use a factory that decides which instance to instantiate and whether to store this instance for sharing, thus making it a Singleton. You must store the instance of a specific factory global to one context.

As you can see, what we have done is moving the storing mechanism out of the Singleton and into the SingletonFactory. In our case the class that gets instantiated by the SingletonFactory is hard-coded. We could create a dynamic SingletonFactory to not have to create a new factory every time. The only difference would be that the SingletonFactory’s constructor would take a ‘clazz’ parameter of type Function and return a new instance of the passed class.

That of course isn’t the neatest way to handle the issue. We will now go a step further and use a Context class to bind classes to string identifiers. The Context checks if the class implements the Singleton interface. If that is the case it creates a new SingletonFactory instance assigning the class to it. If you now use the Context.lookup(String) method passing in the identifier, the Factory’s getInstance() operation is being called returning an instance of the assigned class. As you can see this implementation is much more flexible. You do not have to care about whether the class is a Singleton or not. You can also easily substitute the class returned by the Context.lookup(String) method for a given identifier. All you have to care about is that the new class substituting the old one implements the same interface. All this should of course be done declaratively.
A little variation of this approach would be to determine whether to use the SingletonFactory or a normal one not by implementing the Singleton interface but by calling the Context’s bindSingleton() operation or by doing this declaratively. Doing it that way every class could be a potential Singleton without having to change anything inside of it. To achieve all this we need a bunch of new classes and interfaces. These classes or interfaces are:

• Interface org.swacker.designpattern.Singleton:
  
  This interface declares no operations. It is just used to distinguish a Singleton from a normal class.
• Interface org.swacker.naming.Context:
  
  The Context interface declares the operations to bind, unbind and rebind an object to a specific name.
• Interface org.swacker.naming.Factory:
  
  Factory declares the getInstance() operation that should be implemented by all factories.
• Class org.swacker.naming.ClassContext:
  
  ClassContext implements the Context interface. Only classes are allowed to be bound to string identifiers. It gets internally checked whether the passed class is a Singleton using the above explained check mechanism.
• Class org.swacker.naming.SimpleFactory:
  
  SimpleFactory is a simple implementation of the Factory interface that just returns a new instance of the passed class, not storing old ones.
• Class org.swacker.naming.SingletonFactory:
  
  SingletonFactory stores the firstly instantiated instance of a class and returns this instance every time the SingletonFactory.getInstance() operation gets called.

Not every thought has been implemented yet. Including the declarative stuff. The code shown here is also not fully worked out. It are all basic implementations that are right now only intended for explanation reasons. I am planning to offer support for everything I have written above in one of the next releases of the as2lib. If you have any questions or suggestions leave a comment.

To complete this post I’m now going to show you why not just use static methods and variables to implement Singletons. The problems using this approach:

• Everything I told you above would not work using static methods and variables.
• You could not use the constructor to do the core initialization. That means you had to do the core initialization in a static manner. Doing that causes the initialization to be done whether the class is needed or not which would create unnecessary overhead.
• Another major disadvantage is that you could not take advantage of interfaces and inheritance.
• You also could not use ‘this’ directly in one of the static methods becuase it would cause a compile time error. You had to outwit it using eval(”th” + “is”).

This should be enough disadvantages to not even think about implementing a Singleton using static methods and variables.

Basic implementation:

// :: Context :: //
class Context{
        private var state:State;

        public function request():Void{
                state.handle();
        }
        public function setState(aState:State):Void{
                state = aState;
        }
        public function getState():State{
                return state;
        }
}

// :: State :: //
interface State{
        public function handle():Void;
}

// :: ConcreteStateA :: //
class ConcreteStateA implements State{
        public function handle():Void{
                trace(”ConcreateStateA: handle“);
        }
}

// :: ConcreteStateB :: //
class ConcreteStateB implements State{
        public function handle():Void{
                trace(”ConcreateStateB: handle“);
        }
}

// usage
aContext = new Context();
aContext.setState(new ConcreteStateA());
aContext.request();
aContext.setState(new ConcreteStateB());
aContext.request();

This is only one way to change the state. I have chosen this way for simplicity. You could also change the state dynamically depending on for example a local connection or a mouse press etc. It depends on the context.

Basic implementation:

// :: Component :: //
interface Component{
        public function operation():Void;
}

// :: Leaf :: //
class Leaf implements Component{
        private var number:Number;

        public function Leaf(aNumber:Number){
                number = aNumber;
        }
        public function operation():Void{
                trace(”Leaf ” + number + “: operation“);
        }
}

// :: Composite :: //
class Composite implements Component{
        private var children:Array;

        public function Composite(){
                children = new Array();
        }
        public function operation():Void{
                for(var i:Number=0; i < children.length; i++){
                        children[i].operation();
                }
        }
        public function addComponent(aComponent:Component):Number{
                return children.push(aComponent)-1;
        }
        public function removeComponent(aNumber:Number):Void{
                children.splice(aNumber, 1);
        }
        public function getChild(aNumber:Number):Component{
                return children[aNumber];
        }
}

// usage
var aComponent:Composite = new Composite();
aComponent.addComponent(new Leaf(0));

var aComposite:Composite = new Composite();
aComposite.addComponent(aComponent);
aComposite.addComponent(new Leaf(1));
var leaf2 = aComposite.addComponent(new Leaf(2));
aComposite.addComponent(new Leaf(3));

aComposite.operation();

trace(”——————————–“);

aComposite.getChild(leaf2).operation();

trace(”——————————–“);

aComposite.removeComponent(leaf2);
aComposite.operation();

/* Output:
Leaf 0: operation
Leaf 1: operation
Leaf 2: operation
Leaf 3: operation
——————————–
Leaf 2: operation
——————————–
Leaf 0: operation
Leaf 1: operation
Leaf 3: operation
*/

Dave Yang already showed on his blog how to implement the Singleton Pattern. Therefore I think I don’t have to rewrite the code. Here’s the link: Singleton Pattern by Dave Yang.