Creating a real singleton class in Delphi 5
Abstract:The article describes how to create a class that follows the singleton
pattern. The class described will take care of the singleton requirements and
effects itself, effectively leaving the programmer to use the class as any
others.
Creating a real singleton class in Delphi
by Lasse V錱s鎡her Karlsen, Systems Developer for Cintra Software Engineering
Errata 1. Implementation of TSingleton.NewInstance had the first test switched,
the one that checked if the Instance variable was assigned or not. -- Fixed
11-08-2000 - Thanks to the people that emailed me about this --
2. Overzealous fix for the first errata, the NewInstance method should now
work as stated. -- Fixed 11.08.2000 --
A singleton is a class that supports the creation of just one object. It's
like your computer -- there's just one keyboard. So if you were writing Delphi
code that simulated your computer, you would want just one object instance to
deal with keyboard read, write, and control activities.
Articles about singleton classes are rare but there are a few on the Internet.
I've seen some in magazines too. But none of these articles include sample code
to create a real singleton class.
By "real" I mean that the class itself enforces the one-instance requirement,
instead of leaving that task to the programmer. All of the articles I have
seen so far have required the programmer to use the class in a special way to
enforce the singleton pattern.
In this article you will see how to create a proper singleton class that
includes logic to enforce the one-instance rule.
Note: The conventional approach, in which the one-instance rule is maintained
explicitly by the programmer, is not without merit. Real singleton classes like
the one I present here effectively hide the details and awareness of the
singleton pattern from the programmer. The programmer is relieved of the task
of enforcing the pattern -- that's good -- but the programmer may also be
unaware of the special nature of the class, which is bad. If youdo
n't know
that the class is a singleton class then
all sorts of errors can crop up. You
have been warned!
Writing the code
Our goal is to write a class that can be used like this:
procedure Test;
var
s1, s2 : TSingleton;
begin
s1 := TSingleton.Create;
s2 := TSingleton.Create;
//do
something with s1 and s2 here
s2.Free;
s1.Free;
end;
(I've left out the try...finally blocks and other safeguards for simplicity's
sake.)
The goal is to make the TSingleton class behave in such a way that both s1 and
s2 refer to the same object. Here's what we have todo
:
Instantiate the object the first time Create is called (when s1 is created
above)
Ensure that when another Create is executed (s2 above), the existing object
is reused instead of another one created
Avoid destroying the object when it's not the last reference that is destroyed
(when s2 is freed)
Destroy the instance when the last reference is destroyed (when s1 is freed
above)
Is there a way to override the creation and destruction of a new object in
Delphi? There sure is. In the TObject class (the mother of all objects {pun
intended}), there are two methods we can use:
class function NewInstance: TObject;
virtual;
procedure FreeInstance;
virtual;
NewInstance is responsible for allocating memory to hold a new instance of the
class, and FreeInstance is responsible for freeing that memory when the class
is through with it.
These methods control what happens when the object is created and when the
object is destroyed. If we overwrite this code, we can alter the default
behavior to work the say a singleton class requires. Nothing to it.
Tracking instances is a little trickier. We must:
Keep track of each existing instance of our class
Keep track of how many references there are to this instance
Create a new object only when no instance exists
Destroy the object when the last reference is removed
To keep track of an existing instance, we will use a global variable. Actually,
the variable will ultimately be declared inside the Implementation part of a
unit so it won't be a true global variable. But the scope must be sufficient
to track all the Create and Free calls. We'll call the variable Instance so
we know what it refers to.
As for keeping track of how many references exist, we need another variable.
We can it inside the class or make it a sort-of global like Instance. I'll opt
for the latter way butdo
what you feel is best. I'll name this variable
Ref_Count.
We now have two variables:
var
Instance : TSingleton = nil;
Ref_Count : Integer = 0;
I initialize the variables so that initially theydo
n't contain any garbage.
I know that the compilerdo
es this automatically, so this is just a readability
issue.
We'll need to declare the TSingleton class above the variable block, and if
you take a look at the example files that you cando
wnload at the end of this
article you'll see that I've put the declaration in the interface part of the
unit so that it's visible outside of it.
Here's the declaration of the TSingleton class:
type
TSingleton = class
public
class function NewInstance: TObject;
override;
procedure FreeInstance;
override;
class function RefCount: Integer;
end;
I added the RefCount function so that we can see that it actually works, and
it's often handy to be able to read how many references to the object exist.
It's not required, however, so youdo
n't have to add it to your singleton
classes if youdo
n't need it.
Ok, now for the implementation of the three methods:
procedure TSingleton.FreeInstance;
begin
Dec( Ref_Count );
if ( Ref_Count = 0 ) then
begin
Instance := nil;
// Destroy private variables here
inherited FreeInstance;
end;
end;
class function TSingleton.NewInstance: TObject;
begin
if ( not Assigned( Instance ) ) then
begin
Instance := inherited NewInstance;
// Initialize private variables here, like this:
// TSingleton(Result).Variable := Value;
end;
Result := Instance
Inc( Ref_Count );
end;
class function TSingleton.RefCount: Integer;
begin
Result := Ref_Count;
end;
And that's it!
When you call TSingleton's constructor, a call is placed to the NewInstance
method declared in TObject. This method allocates memory to hold the new
object and returns it to the constructor. The constructor uses that memory
and eventually returns a pointer to the memory to the code that called the
constructor. This pointer is usually stored in a variable while the object
is in use.
I have overridden the NewInstance method so it will allocate the memory only
if no instance of the class exists. If there is an existing instance, the
function simply returns that instance to the constructor so it will be reused.
If we call the constructor three times, an object is created only the first
time. The other two calls simply reuse the first object. The reference count
variable let us know that we have three references to the single instance.
When the program calls the destructor, a call to FreeInstance is placed to
free the memory allocated in the constructor. This method, too, is overridden
so that the object is destroyed only when the last reference is removed.
If you intend to use a singleton in a multithreaded program, treat the object
as you would any variable you share between threads. Because that's just what
youdo
: share it between the threads. So you must take special care when
changing data.
Simplicity itself
As you can see, creating a singleton classdo
esn't require much effort, just
the right knowledge and a few lines of code. My code works fine in Delphi 5.
The technique will probably work fine with older versions of Delphi, but I
haven't tested it so Ido
n't make any guarantees.
Before I give you the file to play with, let me give you a few words of
warning.
Don't descend from a singleton class. The reason for that is that there is
only one instance and reference count variable. If you derive two classes from
TSingleton, only one object will be created. The other class will reuse that
object, which will be an instance of a different class.do
n't godo
wn that
road!
You can't make singleton components for the simple reason of ownership. A
component is owned by a form and one component can't be owned by several other
components.
Remember that the constructor and destructor get called for each new reference
as they are created and destroyed.do
n't initialize private variables in the
constructor anddo
n't free them in the destructor. Instead, build that code
into the NewInstance and the FreeInstance methods, as shown in the comments.
The order of adjusting Ref_Count in the two methods in conjunction with the
rest of the code in those two methods is critical. It has todo
with proper
creation and destruction when something goes wrong. If your initialization
code raises an exception, the order ofdo
ing things like shown above will
make sure that the class is destroyed properly. Alter this code at your peril!
The file that you cando
wnload is just a copy of the unit that declares the
singleton class described in this article.
Link to file: CodeCentral entry 15083.
I'm sure you can find a few places where a singleton class comes in handy and
now you have the tools to create your own! If you want to get in touch with me,
my email is lasse@cintra.no.