Author: Max Kleiner

The Choice Design Pattern is new and relies on interfaces and runtime associations. 
No aggregation or composition between classes are needed.

Answer:

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;
3   end;


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 
objects. 
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. 
4   
5   TCheckFormatA = class(TInterfacedObject, IChoicePattern)
6   public
7     procedure doPatternSearch;
8   end;
9   
10  TCheckFormatB = class(TInterfacedObject, IChoicePattern)
11  public
12    procedure doPatternSearch;
13  end;
14  
15  3. We need a worker-class which calls the runtime interface-methods: 
16  
17  <!--CS-->TDirWorker = class
18    procedure callCheck(myInst: IChoicePattern);
19  end;


4. Now we implement the Interface Classes and the Worker Class too: 
20  
21  procedure TCheckFormatA.doPatternSearch;
22  var
23    ldbPath: string;
24  begin
25    if FileExists(extractFileDir(application.exeName) + '\' + DBNAME) then
26      ldbPath := extractFileDir(application.exeName) + '\' + DBNAME;
27    messageDlg('formatASearch doing', mtInformation, [mbok], 0);
28  end;
29  
30  procedure TCheckFormatB.doPatternSearch;
31  var
32    ldbPath: string;
33  begin
34    if OpenDialog1.Execute then
35      ldbPath := openDialog1.FileName;
36    messageDlg('formatBSearch doing', mtInformation, [mbok], 0);
37  end;
38  
39  procedure TDirWorker.callCheck(myInst: IChoicePattern);
40  begin
41    myInst.doPatternSearch;
42    messageDlg('do_some_Work', mtInformation, [mbok], 0);
43  end;


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 
runtime: 
44  
45  procedure TMainFrm.Button1Click(Sender: TObject);
46  begin
47    with (TDirWorker.Create) do
48    begin
49      callCheck(TCheckFormatA.create);
50      callCheck(TCheckFormatB.create);
51      Free;
52    end;
53  end;