Part II. Abstract Factories
In Part I of this two-part article, we talked about basic instantiation and different way constructors can work. In Part II we looked at using factory methods. In this article we'll be looking at how to implement an abstract factory.
An Abstract Factory
An abstract factory is used when we don't necessarily know what type of object we will be needing to build. Essentially, what we are doing is implementing the factory method using a strategy or state pattern.
To get started, let's say we have two concrete classes derived from the same base class:
public class Four : Number
{
internal Four() { }
}
public class Five : Number
{
internal Five() { }
}
And we need an abstract factory for instantiating our object:
public abstract class NumberFactoryBase
{
public abstract Number Build();
}
And finally we need two different factories that are derived from our abstract NumberFactoryBase: one that builds a Four object and one that build a Five object.
internal class FourFactory : NumberFactoryBase
{
public override Number Build()
{
return new Four();
}
}
internal class FiveFactory : NumberFactoryBase
{
public override Number Build()
{
return new Five();
}
}
Now, the idea is to just have a class deriving from NumberFactoryBase that will know which object to build (a Four or a Five).
Abstract Factory Implemented as a Strategy
First, let's look at implementing the abstract factory method using the strategy pattern. The strategy pattern let's us set which type of object will be instantiated by setting a property of the factory object. To set the strategy that determines which type of object will be instantiated, we'll create a NeedMore enum
public enum NeedMore
{
Fours, Fives
}
and we'll use this NeedMore enum as a parameter to send to the factory to determine which object will be instantiated.
public class NumberFactory : NumberFactoryBase
{
#region Constructor
public NumberFactory(NeedMore whatsNeeded)
{
m_fourFactory = new FourFactory();
m_fiveFactory = new FiveFactory();
SetWhatsNeeded(whatsNeeded);
}
#endregion
#region Member Variables
private NumberFactoryBase
m_strategy,
m_fourFactory,
m_fiveFactory;
#endregion
#region Strategy Setter
public void SetWhatsNeeded(NeedMore whatsNeeded)
{
switch (whatsNeeded)
{
case NeedMore.Fours:
m_strategy = m_fourFactory;
return;
case NeedMore.Fives:
m_strategy = m_fiveFactory;
return;
default:
throw new ArgumentOutOfRangeException("Unexpected NeedMore value");
}
}
#endregion
#region Overrides
public override Number Build()
{
return m_strategy.Build();
}
#endregion
#region Internals
public enum NeedMore
{
Fours, Fives
}
#endregion
}
So now, when we're using our factory we can do the following:
NumberFactory factory = new NumberFactory(NumberFactory.NeedMore.Fours);
Number objFour = factory.Build();
factory.SetWhatsNeeded(NumberFactory.NeedMore.Fives);
Number objFive = factory.Build();
Abstract Factory Implemented as a State
The main difference in changing our implementation from a strategy pattern to a state pattern is that now we'll let the factory decide which strategy to use (so not it will depend on the state of the factory). The example below demonstrates our abstract factory now with a state implementation instead of a strategy implementation.
public class NumberFactory2 : NumberFactoryBase
{
#region Constructor
public NumberFactory2()
{
m_fourFactory = new FourFactory();
m_fiveFactory = new FiveFactory();
m_state = m_fourFactory;
}
#endregion
#region Member Variables
private NumberFactoryBase
m_state,
m_fourFactory,
m_fiveFactory;
#endregion
#region Overrides
public override Number Build()
{
Number result = m_state.Build();
// switch the state each time
// from four to five
// or five to four
if(m_state == m_fourFactory)
m_state = m_fiveFactory;
else
m_state = m_fourFactory;
return result;
}
#endregion
}
So now when we use our factory, we no longer get to specify which object we want built, because it is managed by the state of the factory:
NumberFactory2 stateFactory = new NumberFactory2();
objFour = stateFactory.Build();
objFive = stateFactory.Build();
In the next article, we will take a look at the builder pattern for object instantiation.
Until next time,
Happy coding