Author: Max Kleiner
The Choice Design Pattern is new and relies on interfaces and runtime associations.
No aggregation or composition between classes are needed.
The Choice Pattern needs one interface, n-classes which supports the interface and
a worker-class to provide the choice of an algorithm at runtime. The Choice Pattern
is like the Strategy Pattern, but smaller and more runtime in his behaviour.
With interfaces we don't have to concern about memory management.
Interface references are managed through reference-counting, which depends on the
_AddRef and _Release methods inherited from IUnknown. When an object is referenced
only through interfaces, there is no need to destroy it manually; the object is
automatically destroyed when the last reference
to it goes out of scope.
The following restrictions apply.
The member List can include only methods and properties.
Fields are not allowed in interfaces.
Interfaces have no constructors or destructors. They cannot be instantiated, except
through classes that implement their methods.
Methods cannot be declared as virtual, dynamic, abstract, or override. Since
interfaces do not implement their own methods, these bindings have no meaning. So
let's practice the Choice Pattern in 5 steps:
1. We need an Interface in order to be type-compatible.
1 IChoicePattern = interface
2 procedure doPatternSearch;
2. We declare 2 or n classes.
A class from an Interface can support/implement multiple interfaces.
TInterfacedObject implements the methods of IUnknown, so TInterfacedObject
automatically handles reference counting and memory management of interfaced
One of the concepts behind the design of interfaces is ensuring the lifetime
management of the objects that implement them. The AddRef and Release methods of
IUnknown provide a way of implementing this functionality.
5 TCheckFormatA = class(TInterfacedObject, IChoicePattern)
7 procedure doPatternSearch;
10 TCheckFormatB = class(TInterfacedObject, IChoicePattern)
12 procedure doPatternSearch;
15 3. We need a worker-class which calls the runtime interface-methods:
17 <!--CS-->TDirWorker = class
18 procedure callCheck(myInst: IChoicePattern);
4. Now we implement the Interface Classes and the Worker Class too:
21 procedure TCheckFormatA.doPatternSearch;
23 ldbPath: string;
25 if FileExists(extractFileDir(application.exeName) + '\' + DBNAME) then
26 ldbPath := extractFileDir(application.exeName) + '\' + DBNAME;
27 messageDlg('formatASearch doing', mtInformation, [mbok], 0);
30 procedure TCheckFormatB.doPatternSearch;
32 ldbPath: string;
34 if OpenDialog1.Execute then
35 ldbPath := openDialog1.FileName;
36 messageDlg('formatBSearch doing', mtInformation, [mbok], 0);
39 procedure TDirWorker.callCheck(myInst: IChoicePattern);
42 messageDlg('do_some_Work', mtInformation, [mbok], 0);
Here we can see, no myInst.Free is needed. Each object from TCheckFormatA or
TCheckFormatB is automatically destroyed. Interfaces track the lifetime of an
object by incrementing the reference count on the object when an interface
reference is passed, and will destroy the object when that reference count is zero.
5. At least the client calls the Choice Pattern and every object is local at
45 procedure TMainFrm.Button1Click(Sender: TObject);
47 with (TDirWorker.Create) do