Usages of decorator pattern: Factory Decorator

One of the typical usages of Strategy pattern, that I’ve seen in the code “out there”, is the one where it is combined with the Factory pattern. Client has dependencies on factory and strategy interface, where factory produces the instance of concrete strategy, which, in turn, client invokes in order to server the incoming request.

This combination is used since the concrete strategy/algorithm, that is used to serve the request, is known only at run time.

Class diagram of this usage is following:

Typical usage of Factory + Strategy pattern
Typical usage of Factory + Strategy pattern

Here’s, also, an example of a given usage, where MailSender is a client, ShippingMethodFactory is a factory and PriorityMail and RegularMail are concrete strategies:

	public interface IAmShippingMethod
	{
		void ShipToCustomer(Book book, Customer customer);
	}


	public class PriorityMail : IAmShippingMethod
	{
		public void ShipToCustomer(Book book, Customer customer)
		{
			//deliver by priority mail
		}
	}


	public class RegularMail : IAmShippingMethod
	{
		public void ShipToCustomer(Book book, Customer customer)
		{
			//deliver by regular mail
		}
	}


	public interface IAmShippingMethodFactory
	{
		IAmShippingMethod GetShippingMethodFor(Customer customer);
	}


	public class ShippingMethodFactory : IAmShippingMethodFactory
	{
		private readonly IDictionary<MembershipType, IAmShippingMethod> _shippingMethods;

		public ShippingMethodFactory(IDictionary<MembershipType, IAmShippingMethod> shippingMethods)
		{
			_shippingMethods = shippingMethods;
		}

		public IAmShippingMethod GetShippingMethodFor(Customer customer)
		{
			var membershipType = _shippingMethods.Keys.First(type => customer.Has(type));
			return _shippingMethods[membershipType];
		}
	}


	public class MailSender
	{
		private readonly IAmShippingMethodFactory _factory;

		public MailSender(IAmShippingMethodFactory factory)
		{
			_factory = factory;
		}

		public void SendToCustomer(Book book, Customer customer)
		{
			//some logic...
			var shippingStrategy = _factory.GetShippingMethodFor(customer);
			shippingStrategy.ShipToCustomer(book, customer);
		}
	}


	public class CompositionRoot
	{
		public MailSender Bootstrap()
		{
			var shippingMethods = new Dictionary<MembershipType, IAmShippingMethod>
			{
				{ MembershipType.Gold, new PriorityMail()},
				{ MembershipType.Regular, new RegularMail() }
			};
			return new MailSender(new ShippingMethodFactory(shippingMethods));

		}
	}


	public class Customer
	{
		private readonly MembershipType _membershipType;

		public Customer(MembershipType membershipType)
		{
			_membershipType = membershipType;
		}

		public bool Has(MembershipType membershipType)
		{
			return _membershipType.Equals(membershipType);
		}
	}


	public enum MembershipType
	{
		Gold,
		Regular
	}

Recently, while working on one of the projects, I thought about a question: “In case client was not being forced to have (semantic) dependencies to both factory and strategy, what would’ve design looked like?”, and thought about factory decorator came upon. In this case design would look something like this:

Factory Decorator

And the code would look something like this:

	public class ShippingMethodFactory : IAmShippingMethod
	{
		private readonly IDictionary<MembershipType, IAmShippingMethod> _shippingMethods;

		public ShippingMethodFactory(IDictionary<MembershipType, IAmShippingMethod> shippingMethods)
		{
			_shippingMethods = shippingMethods;
		}

		public void ShipToCustomer(Book book, Customer customer)
		{
			var membershipType = _shippingMethods.Keys.First(type => customer.Has(type));
			_shippingMethods[membershipType].ShipToCustomer(book, customer);
		}
	}


	public class MailSender
	{
		private readonly IAmShippingMethod _shippingMethod;

		public MailSender(IAmShippingMethod shippingMethod)
		{
			_shippingMethod = shippingMethod;
		}

		public void SendToCustomer(Book book, Customer customer)
		{
			//some logic...
			_shippingMethod.ShipToCustomer(book, customer);
		}
	}

As for me, client code shouldn’t be bothered with the fact that the request is of dynamic nature and that the factory is needed in order to produce an instance of a class that represents algorithm that needs to be applied for a given request. For this reason, with usage of factory decorator, client code communicates more in domain, rather than implementation specific, terms.
Also, code better aligns with Tell Don’t Ask principle and this has positive repercussions on unit tests, since we can get rid of stubs (in this case factory stub) that return canned concrete strategy and also tests can get a bit more readable.

On the other hand, drawback of this approach is that Factory has to implement Strategy interface and thus conform to it. This can be misleading when reading Factory class, since the names of methods are the ones from Strategy interface.
Also, another drawback of this approach is, since the code is streamlined (client -> factory -> strategy), it can happen that the method signature of Strategy interface has to contain parameter(s) that are not needed by Strategy at all, but only by Factory in order to instantiate appropriate object. In the given example, imagine that Factory doesn’t use membership type information from Customer class in order to decide which concrete strategy is instantiated:

 	var membershipType = _shippingMethods.Keys.First(type => customer.Has(type)); 

but that this decision is based on the current day in the year (e.g. during holidays everyone gets books by priority mail and on other days books are shipped by regular or priority mail), this parameter would have to be added to the Strategy interface, which can be thought of as unrelated information.
Thus, when trying to apply Factory Decorator, for a specific problem, these points need to be taken into account.

If I was to summarize this approach I guess it would be: Factory Decorator trades interface readability for client transparency.