Comments for Creating a real singleton class in Delphi 5

Creating a real singleton class in Delphi 5

2007-07-30T08:16:09-07:00

I would also have a doubt in implementation of the pure pattren as it voliates the rule of OOP by adding globals inside the unit which i dont think so is a good way for implementation. Similarly,the argument that user will not aware the creation control is also misleading, Pattren suggests us to indicate this neccessity to the user so he can understand what kind of object is ebing used (we can find hunreds of examples in each API [.NET, Java]).But i can give a benefit of doubt as well becuase As for as i can observe its hard to implement a pure Singleton in the Delphi (not counting .NET additions though).

re: It's not a Singleton

2007-06-27T03:33:10-07:00

Sorry you made mistake as you are assigning a value to constant variable.

Creating a real singleton class in Delphi 5

2003-12-01T00:35:01-08:00

Additionally, this class can not be rerived from any class, that has some initializations in its constructor. This narrows its usage to direct descendant of TObjects.

Creating a subclassable singleton class in Delphi

2002-12-13T01:38:17-08:00

I've not been programming in Delphi for a few years now, but I have been using singleton classes in Perl which you can subclass and get new instance data. I modified your example to do the same. Subclassing is easy: just create a new subclass whereby you initialize instance fields in the InitInstance() method that you must override.See the article I wrote on my website: http://www.skybound.nl/articles/delphi-singleton/

Creating a real singleton class in Delphi 5 - one more implementation

2002-09-29T01:21:36-07:00

Let's touch this veeery old topic again, hoping it will be helpful. I'm always using the following singleton implmenetation. Although it has some "minuses" (default constructor needed, no inheritance, etc), it handles lazy creation / destruction _without_ reference counting, with minimal number of overriden methods.

TSingleton = classprivate    constructor Create;public    class function Instance: TSingleton;     destructor Destroy; override;end;implementationvar FInstance: TSingleton = nil;class function TSingleton.Instance: TSingleton;begin    if Assigned(FInstance) then        FInstance := TSingleton.Create;    Result := FInstance;end;constructor TSingleton.Create;begin    { nothing special here ... }end;destructor TSingleton.Destroy;begin    FInstance := nil;    { clean things up ... }    inherited Destroy;end;initializationfinalizationif Assigned(FInstance) then    FInstance.Free;end.

re: Nice in theory, but...

2002-08-18T03:40:04-07:00

I tried to use the singleton pattern you and Marco Cantù showed in The Delphi Magazine No.44, with my forms, but it doesn't seem to work and has problems. This is the code of my TtmplSingleton form which has to behave in a singleton manner. But it returns exceptions on 2nd and forth calls to Create constructor. What should I do?

re: Nice in theory, but...

2000-08-29T08:54:46-07:00

I think that I must disagree with SOME of your statements:1. Absolutely correct, the authors code does not give the ability to inherit from the singleton. But with some work it IS possible. 2. I disagree with this, the client does not know the internals of the NewInstance method, they simply request an object by calling Create, similar to say a TButton.3. I disagree, why have a singleton if only one client will call some methods & then free it?4. I disagree, where better to initialize an object, then in its constructor?BTW, I have seen the singleton you reference in The Delphi Magazine and although I found it quite interesting, I felt it was quite alot of work and code for a singleton.

re: THIS is how a Singleton is implemented.

2000-08-29T08:26:42-07:00

I am afraid I do not agree with you Serge. Reference counting singletons is the better way to handle lifetime management of the singleton. Without reference counting, one of many client objects of the singleton may inadvertantly free the singleton while another object still maintains a reference to it. Also inheritable singletons are possible and is not something that is dependant upon the design pattern, but depends upon the implementation of the design pattern.

THIS is how a Singleton is implemented.

2000-08-27T11:15:55-07:00

I'm very sorry, but the way you implement singletons is NOT the way to do it. I do agree with your remarks about subclassing singletons etc., but that's inherent in Singletons and not just a Delphi issue.Here is the code for a better version:unit Singleton;interfacetype TSingleton = class protected class function AccessInstance(const iAccessType: integer): TSingleton; public constructor Create; destructor Destroy; override; class function Instance: TSingleton; class procedure ReleaseInstance; end;implementation{ TSingleton }constructor TSingleton.Create;begin inherited Create; {Whatever is necessary for the object}end;destructor TSingleton.Destroy;begin {Whatever necessary for object} inherited Destroy;end;class function TSingleton.AccessInstance(const iAccessType: integer): TSingleton;const Singleton: TSingleton = nil;begin case iAccessType of 0: begin Singleton.Free; Singleton := nil; end; 1: if not Assigned(Singleton) then Singleton := TSingleton.Create; end; Result := Singleton;end;class function TSingleton.Instance: TSingleton;begin Result := AccessInstance(1);end;class procedure TSingleton.ReleaseInstance;begin AccessInstance(0);end;initializationfinalization TSingleton.ReleaseInstance;end.No reference counting, and you're sure the singleton gets cleaned up in the end.Thanks to the ModelMaker people for this solution...Serge.

It's not a Singleton

2000-08-20T21:06:17-07:00

I agree with Halvard, and would go as far as to say "This class does not implement the Singleton pattern". I've never heard of reference-counted Singletons before.