The Wiert Corner – irregular stream of stuff

If you auto-configure, then at least try searching the tools you need:

[WayBack] Yeah right Delphi 10.2 Tokyo (for which the shortcut – unlike the Berlin one – does not contain the word Tokyo), they are right on the Windows PATH wher… – Jeroen Wiert Pluimers – Google+

–jeroen

A blast from the past: my 2009 answer to [WayBack] What Design Patterns do you implement in common Delphi programming? – Stack Overflow which is still very much relevant today.

TL;DR

Every Delphi programmer uses the factory pattern as it is an intrinsic part of how components at design time work.

So he were go:

Only a minority of the Delphi developers knows that every Delphi developer uses a Factory pattern (delphi.about.com has an example in “regular” Delphi), but then implemented using virtual Create constructors.

So: time to shed some light on that :-)

Virtual constructors are to classes like virtual methods are like object instances.

The whole idea of the factory pattern is that you decouple the logic that determines what kind (in this case “class”) of thing (in this case “object instance”) to create from the actual creation.

It works like this using virtual Create constructors:

TComponent has a virtual Create constructor so, which can be overridden by any descending class:

type
  TComponent = class(TPersistent, ...)
    constructor Create(AOwner: TComponent); virtual;
    ...
  end;

For instance the TDirectoryListBox.Create constructor overrides it:

type
  TDirectoryListBox = class(...)
    constructor Create(AOwner: TComponent); override;
    ...
  end;

You can store a class reference (the class analogy to an object instance reference) in a variable of type ‘class type’. For component classes, there is a predefined type TComponentClass in the Classes unit:

type
  TComponentClass = class of TComponent;

When you have a variable (or parameter) of type TComponentClass, you can do polymorphic construction, which is very very similar to the factory pattern:

var
  ClassToCreate: TComponentClass;

...

procedure SomeMethodInSomeUnit;
begin
  ClassToCreate := TButton;
end;

...

procedure AnotherMethodInAnotherUnit;
var
  CreatedComponent: TComponent;
begin
  CreatedComponent := ClassToCreate.Create(Application);
  ...
end;

The Delphi RTL uses this for instance here:

Result := TComponentClass(FindClass(ReadStr)).Create(nil);

and here:

// create another instance of this kind of grid
SubGrid := TCustomDBGrid(TComponentClass(Self.ClassType).Create(Self));

The first use in the Delphi RTL is how the whole creation process works of forms, datamodules, frames and components that are being read from a DFM file.

The form (datamodule/frame/…) classes actually have a (published) list of components that are on the form (datamodule/frame/…). That list includes for each component the instance name and the class reference. When reading the DFM files, the Delphi RTL then:

1. finds about the components instance name,
2. uses that name to find the underlying class reference,
3. then uses the class reference to dynamically create the correct object

A regular Delphi developer usually never sees that happen, but without it, the whole Delphi RAD experience would not exist.

Allen Bauer (the Chief Scientist at Embarcadero), wrote a short blogarticle about this topic as well. There is also a SO question about where virtual constructors are being used.

Let me know if that was enough light on the virtual Create constructor topic :-)

This resulted in this interesting comment by Kenneth Cochran:

Factory pattern implementations in other languages use ordinary static functions (or class functions for pascalites). As such they are capable of returning null(nil). A Delphi constructor, like the nameless constructors in other languages, will always return an object reference unless you raise an exception. You are free, of course, to use a class function just as easily if the need arises.

–jeroen