Abstract Factory Thoughts

Further miscellaneous thoughts on Abstract Factory

Abstract Factory is presented as part of this talk. Here are some footnotes:

Implementation variants for Abstract Factory

The GOF style abstract factory, uses polymorphic override. This is shown using UML and explained in my talk

You could alternatively have conditional code & class registry implementation variations of abstract factory too. I talk about factory method (as opposed to Abstract Factory) being implemented using these variants here and here. However the standard GOF (Gang of Four) polymorphic override technique is actually quite a good implementation choice for abstract factory since we now have a dedicated factory class and we simply override the create methods to make a specific factory. To do a registry version of this would be ok as well, but not as polymorphically elegant.

The "which version of the implementation do we want" switch

How do the three variants known which version/family of classes to return?

The traditional GOF abstract factory remembers the family you need ("the switch") via the act of instantiatiating the required subclass (with all creational methods polymorphically overridden). See diagram.

A registry based version of an abstract factory (or even regular 'factory method') factory could set a switch once and subsequently remember which version/style of implemenation to use.

  factory.SetFamily('b version')
  factory.CreateProduct1()
  factory.CreateProduct2()
  factory.CreateProduct3()

rather than having to pass in a parameter each time.

  factory.CreateProduct1('a version')
  factory.CreateProduct2('a version')
  factory.CreateProduct3('a version')

What do the factory methods on an Abstract Factory do?

The factory methods on an Abstract Factory should, in my opinion, should

	only create 'products' - which are instances of classes
	should have the phrase 'create' somewhere in its name e.g. CreateProd1, or CreateProd2
	each product should be of a different class type
	should not do any real work or computation

I once saw a presentation on Abstract Factory where the factory methods on the concrete abstract factory class actually did complex computational work (each one did something different) and all returned a result class of the same type (a data set, as it happens). This is not abstract factory. The methods in the factory should not have done any real WORK just merely returned DIFFERENT 'products'. Products are a bunch of different classes which are meant to be instantiated as a family of classes, which typically work together. Thus the idea of an 'abstract factory class generating a FAMILY of DIFFERENT but relatedclasses' was entirely missing, and this it seems to me to be the essence of abstract factory. What was being actually presented was simply a compile time choosing of one of two different implementations of an interface, which I call the Interface Pattern and discussed here.