Re: Singleton

Chris Rolliston wrote:

By the by, do you have any objection to the main part of my original
suggestion, which was to define an interface for the singleton and so
hide the singleton class wholesale in the implementation section of the
unit?

It really makes it (almost) impossible to create a second instance, but
comes with several drawbacks:

- If you have properties in your singleton class then you need to write
explicit accessor methods (GetPropery, SetProperty).

- You introduce reference counting just to avoid a finalization section. (I know that initialization and finalization should be avoided when possible)

- You can't pass your singleton as a TObject (Ok, you normally don't
pass pointers to your singleton around ;-) )

The interface is of course easily replaced with an abstract class:

type
TCustomSingleton = class abstract(TObject)
strict protected
function GetMyFirstProperty: Integer; virtual; abstract;
procedure SetMyFirstProperty(const Value: Integer); virtual; abstract;
public
property MyFirstProperty: Integer read GetMyFirstProperty write SetMyFirstProperty;
procedure MyFirstProcedure; virtual; abstract;
end;

The interface version looks like this:

type
ISingleton = interface
function GetMyFirstProperty: Integer;
procedure SetMyFirstProperty(const Value: Integer);
property MyFirstProperty: Integer read GetMyFirstProperty write SetMyFirstProperty;
procedure MyFirstProcedure;
end;

Here we have the version without seperation of interface and implementation types:

type
TSingleton = class sealed(TObject) // sealed prevents the constructor check to be circumvented
private
FMyFirstProperty: Integer;
class var FInstance: TSingleton;
public
property MyFirstProperty: Integer read FMyFirstProperty write FMyFirstProperty;
constructor Create; // fires an exception when FInstance <> NIL
procedure MyFirstProcedure;
end;

None of this solutions is perfect, so YMMV.

The first solution suffers from verbosity and the need to use a finalization section. It forces you to wirte accessor methods.

The second solution forces you to create accessor methods. You also have to implement reference counting.

The third solution needs a finalization sectio.

--
Regards
Jens
.

Relevant Pages

  • Re: Singleton
    ... support for a new "singleton" keyword like this: ... property MyFirstProperty: Integer read FMyFirstProperty write ... procedure MyFirstProcedure; ...
    (borland.public.delphi.non-technical)
  • Re: Windows Service in VB
    ... Your service needs to expose an interface via .Net remoting. ... and register the public class as a well-known singleton. ... You also need to create a WinForms app that can be run by logged-in users. ... if your client app just wants to call methods on the service's remoted ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Singleton & Self := in constructor
    ... > I want to enforce singleton behavior in my TObject derived ... > The basic idea is that clients can call the Constructor any ... But it is much simpler to just use an interface ...
    (borland.public.delphi.language.objectpascal)
  • Re: Singleton
    ... I don't usually go to a string factory or a list factory to ... If you have an abstract DOM interface, for example, and the implementation ... To me it's very clear to go to the DomFactory or singleton ... As mentioned in my posting you unit test a class separate from the ...
    (comp.object)
  • Re: Factory und Interface zusammenpacken?
    ... Bisher habe ich es so gemacht dass ich ein Interface habe, ... weitere Klasse, eine Factory-Method-Klasse, über die ich jetzt eine der ... Dein Problem ist, dass du eine einheitliche Struktur brauchst, um die Singleton Instanzen zu erzeugen, wenn ich das richtig verstanden habe, oder? ... class DBConfig implements Config, Singleton ...
    (de.comp.objekt)