In my earlier post, I mentioned you could use the new generic collection classes in Delphi 2009 to store anonymous methods instead of data. I wanted to try this out so I came up with the scenario of implementing factory classes as an excuse to experiment.

Factories can be a very useful way to centralise the creation logic for classes. Very often you see it when you have a base class and a whole bunch of different descendant classes and you want to do the creation in one place. Let’s say you have a reporting application. You may have a base report and a bunch of descendant reports, and you want to enforce some consistency over property values for the different reports that are set at the time of creation. Having these spread around every different place a report could be created may be error-prone. Alternatively, maybe you want to get away from the massive if…then..else blocks you often see in this situation. A Report Factory can give you one place to make sure all reports get created in the certain way, and also let the client code simply request a report by name and have the correct concrete report class created for them.

Problem is usually this means writing a new factory each time you want this, plus creating factory mapping classes to register each concrete report. This is not only a whole bunch of effort and unnecessary classes, it’s more new code to debug.

Instead, I thought I’d try creating a single factory class, that uses Generics to allow you to change the key used to request an instance, and that uses Anonymous Methods to do the creating so as to avoid the necessity for mapping classes. Sticking with my report scenario above, here’s how I wanted to instantiate it:

  ReportFactory := TFactory.Create;

Where the first generic parameter is the type of the key I will use to request a report, in this case a string representing the report name, and the second is the base type I want the Factory to return.

Here’s how I wanted to register new concrete implementations:

  ReportFactory.RegisterFactoryMethod('Malcolm''s Report',
                  function : TBaseReport
                  begin
                    Result := TReportFlexible.Create(rnReportMalcolm);
                    // other property setting/setup code
                  end);

You simply pass in the key value and the anonymous method that will be invoked to do the creation. Lastly, I want to retrieve a particular instance of my report by calling GetInstance on the factory passing in the key value.

  Report := ReportFactory.GetInstance('Malcolm''s Report');

Remember however, the type of the key value and the base type of the returned objects should be configurable via generic parameters.

Here’s the class definition I came up with:

  TFactoryMethod = reference to function : TBaseType;

  TFactory = class
  private
    FFactoryMethods : TDictionary>;
    function GetCount: Integer;
  public
    constructor Create;
    destructor Destroy; override;
    property Count : Integer read GetCount;
    procedure RegisterFactoryMethod(Key : TKey;
                      FactoryMethod : TFactoryMethod);
    procedure UnregisterFactoryMethod(Key : TKey);
    function IsRegistered (Key : TKey) : boolean;
    function GetInstance(Key : TKey) : TBaseType;
  end;

As you can see, TKey is the name of the generic parameter representing the type I want to use to request a concrete instance of the base type specified in TBaseType.  RegisterFactoryMethod lets you register an anonymous method of type TFactoryMethod which as we already discussed will do the creating, and there is a matching UnregisterFactoryMethod to remove a key\method pair. GetInstance is there, taking the generic parameter TKey and returning an instance of the base type. There are also a couple of methods to check if a particular key is already registered and another to return the number of registered keys.

Nothing there is terribly interesting if you’ve already played with generic types. However, for me the interesting part is I’m storing the key/method pairs in a TDictionary<TKey, TFactoryMethod<TBaseType>>.  Storing the anonymous method and the key in the dictionary is pretty straightforward:

procedure TFactory.RegisterFactoryMethod(Key: TKey;
  FactoryMethod: TFactoryMethod);
begin
  if IsRegistered(Key) then
    raise TFactoryMethodKeyAlreadyRegisteredException.Create('');

  FFactoryMethods.Add(Key, FactoryMethod);
end;

and retrieving it and executing it is equally so.

function TFactory.GetInstance(Key: TKey): TBaseType;
var
  FactoryMethod : TFactoryMethod;
begin
  if not IsRegistered(Key) then
    raise TFactoryMethodKeyNotRegisteredException.Create('');

  FactoryMethod := FFactoryMethods.Items[Key];
  if Assigned(FactoryMethod) then
    Result := FactoryMethod;
end;

With that, we’ve got a very reusable Factory class, so I should have no excuse for avoiding them in the future. Of course, this is a fairly simplistic implementation, it doesn’t handle pipelining during the creation process for example, but this would be relatively straight-forward to add with more anonymous methods stored in a TList<T> for example.

Anyway, hopefully this little experiment has sparked some thoughts in you. The source for both the class and a client implemented as unit tests is available from my delphi-experiments repository on github.

Meanwhile I’m off to do some more playing. Next post will probably be the Pooling example I mentioned earlier but somehow forgot to post.

On the recent Delphi 2009 roadshow in Australia, I had a few people ask me about the new TDictionary<TKey, TValue> container in Generics.Collections. If you haven’t played with it yet,  Roland Beenhakker has a nice write up on using it, but most of the questions I was getting were not about how to use it, but about what it’s for.

The way I try and explain it is by stepping back and looking at collections that people already are used to. Leaving implementation details aside, a lot of the Delphi collections store values and let you retrieve those values using a key.

For example, a TStringList lets you store strings indexed by an integer value. So in this case, the value would be a string and the key would be an integer. A TList lets you store pointers and retrieve them using an integer. Again, the key is an Integer, the value is a pointer.

The next step is to think about TList<T>. It’s not that different, the key is still an integer, just the value can be parameterised using generics.

If you’re ok with that, then a TDictionary<TKey, TValue> is pretty easy to understand. It’s a generic container that lets you parameterise not only the value, but the key also. So, to get somewhat similar behaviour to a TStringList, you could use a TDictionary<integer, string>. Now, of course the implementation details of how TDictionary would store those strings is wildly different to a TStringList, but in terms of understanding it, I think it helps.

Equally, a TList<T> might be replaced in broad terms with a TDictionary<Integer, T>, with T being whatever type you like.

The really cool thing though, is that the key part does not have to be an Integer. You could instead of TDictionary<Integer, String> do something like TDictionary<string, string>, so a string could be retrieved by using another string as a key. If you’re trying to think of an example of that, what about the TDictionary’s real world namesake, a dictionary. The key string would be the word, the definition would be the Value.

Further, it could be TDictionary<TGuid, TState>, where you might be using a GUID as a sessionID to retrieve an object that stores your session state in some sort of distributed system.

An interesting take on this is to use a TDictionary to store code in the form of anonymous methods. Anonymous methods are defined as types, so no reason they can’t be stored in a collection just like data. I find this really interesting. If you’re a fan of using table-driven development to replace convoluted if..then…else or case statements, this might spark some ideas. In fact in my next blog post I’ll show an example of a generic Factory implementation that uses a TDictionary internally to store anonymous factory methods.

Anyway, there is a lot more to know about TDictionary’s, such as hashing functions, comparers, etc, but hopefully this has at least given you a high-level understanding of where you might look at using them.