The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,280 other followers

Delphi virtual constructors: example of the “Factory” design pattern (via: Stack Overflow)

Posted by jpluimers on 2013/07/18

I bumped into the below answer that I gave a while (what is 4 years in a developer’s life ) on StackOverflow.

It is about Delphi Design Patterns. Sepcifically the Factory Pattern, and explains how virtual constructors implement it.

They are one of the 3 corner stones on which the component based Delphi form designer and object inspector are built:

  • Virtual constructors
  • Properties (events are just a special form of property)
  • Run-Time Type Information.

So here it goes:

Only a minority of the Delphi developers knows that every Delphi developer uses a Factory pattern ( 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:

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

For instance the TDirectoryListBox.Create constructor overrides it:

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

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:

  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:

  ClassToCreate: TComponentClass;


procedure SomeMethodInSomeUnit;
  ClassToCreate := TButton;


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

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 blog article 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 :-)


via: What Design Patterns do you implement in common Delphi programming? – Stack Overflow.

6 Responses to “Delphi virtual constructors: example of the “Factory” design pattern (via: Stack Overflow)”

  1. Cobus Kruger said

    I should also mention that when virtual constructors get combined with dynamically-loaded runtime packages and possibly the GetClass/FindClass methods, you have everything you need for a full plugin framework.

    I work on a large system where the standard way of adding new functionality is basically to have some interface and a factory class in a core package, and to have package filenames stored in config. When the package loads, its contained classes can register themselves and be constructed when needed.

    Of course there are other ways to do this that don’t require virtual constructors, but this mechanism has worked wonderfully for us for over a decade.

    • jpluimers said

      Good point. The RTL support for components in the IDE is just that: a plugin framework, and I should have mentioned that. Thanks!

  2. Günther The Beautiful said

    Altough I believe I understand how virtual constructors work, I still don’t get why they’re necessary in the first place. You still need some decision what ClassToCreate is going to be. In your case it’s a TButton. Later, you’re using the virtual constructor of the superclass TComponent. Why not directly use the constructor of TButton? We’ve already made the decision it’s going to be a TButton. The only reason I can think of is making the decision what subclass to use and to actually create an instance in two different methods.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: