Is there an elegant way in Delphi to prevent instantiating a class?

[wuwuxin 28]

I want a class to be pure static, which doesn't allow instantiating (except through a static method for creating singleton).  Is that doable in Delphi?

[David Schwartz 426]

If it's for a singleton, treat it like a Factory method with the constructor hidden. The static method would create it initially if it's NIL, and otherwise return the existing reference.

 

Also, make the constructor Create a strict private member of the class and only reference it through the static factory method in the same unit.

 

 

Edited September 6, 2021 by David Schwartz

[Dalija Prasnikar 1396]

4 hours ago, David Schwartz said:

If it's for a singleton, treat it like a Factory method with the constructor hidden. The static method would create it initially if it's NIL, and otherwise return the existing reference.

 

Also, make the constructor Create a strict private member of the class and only reference it through the static factory method in the same unit.

You cannot make such singleton in Delphi. Public TObject constructor will be always visible and you cannot hide it, 

 

The only way to disable access to the constructor is to define singleton API as interface and have public factory method that returns interface, and then put class implementation inside implementation section of the unit making it inaccessible to the outside world.

[Lars Fosdal 1792]

I wish the "class abstract" declaration would have prevented .Create instantiation.

[Guest]

4 hours ago, wuwuxin said:

I want a class to be pure static, which doesn't allow instantiating (except through a static method for creating singleton).  Is that doable in Delphi?

If i do understand right and that you need a class that is no on the heap, then the answer is no, Delphi doesn't have static classes, though it is easy for the compiler to be made to do so.

On other hand the closest thing to static classes (on the stack or global as preallocated) is to use records, managed records is there to close some of this gap, but still these are records not classes.

 

I wish as a feature to have this declaration for classes

var
  C : TMyClass; static;        // C here is global and will not reside on heap
  D : TMyClass; static; auto;  // D is global and its default constructor will be handled as class constructor, same for its destructor, D is not on the stack

procedure Test;
var
  E : TMyClass; static;        // E reside on the stack
  F : TMyClass; static; auto;  // same as D but on the stack
  G : TMyclass; auto;          // G is on the heap but managed just like strings, means the compiler will manage its constructor and destructor
begin
  E := TMyclass.Create;  // manually managed hence need creating and free manually;
  F.DoSomething;         // the compiler will make sure to call the default Creat and Free in Test, F is on the stack !
  G.DoSomething;         // same as F but G reside on the heap
  

 

[David Schwartz 426]

19 minutes ago, Dalija Prasnikar said:

You cannot make such singleton in Delphi. Public TObject constructor will be always visible and you cannot hide it, 

 

The only way to disable access to the constructor is to define singleton API as interface and have public factory method that returns interface, and then put class implementation inside implementation section of the unit making it inaccessible to the outside world.

I offered up a solution. It may not be ideal, but as you say, that's impossible.

 

So, yeah, we've gotta make do with what we've got. The language purists have managed to keep stuff like this from being properly implemented forever.

There are all kinds of holes and back-doors and things that can only be done with awkward work-arounds in Delphi, and I don't expect that will ever change.

 

Everywhere I've worked has all sorts of unwritten rules about what devs can and cannot do in order to deal with this stuff, and when I dig into the code there are also lots of violations of said rules, mostly by those who made the rules up in the first place. ("Do as I say, not as I do!")

[Fr0sT.Brutal 900]

Is it really so important to disallow instance creation?

[Dalija Prasnikar 1396]

There is another way to prevent instance creation - or at least misuse - having public constructor that raises exception.

 

  TSingleton = class
  private
    class var FInstance: TSingleton;
    constructor CreateSingleton;
    class destructor ClassDestroy;
  public
    constructor Create;
    class function Instance: TSingleton; static;
  end;


class destructor TSingleton.ClassDestroy;
begin
  FInstance.Free;
end;

constructor TSingleton.Create;
begin
  raise Exception.Create('Singleton instance cannot be directly constructed');
end;

constructor TSingleton.CreateSingleton;
begin
  // actual constructor
end;

class function TSingleton.Instance: TSingleton;
begin
  if not Assigned(FInstance) then
    FInstance := TSingleton.CreateSingleton;
  Result := FInstance;
end;

 

 

[Der schöne Günther 316]

Suggestion: Throw the ENoConstructException from System.SysUtils, not a regular Exception 😉

[Stefan Glienke 2002]

If you don't want instances, then don't make it a class - this ain't Java.

[DPStano 15]

can ctor be private?

strict private
  constructor Create;
end;

 

[Dalija Prasnikar 1396]

12 minutes ago, DPStano said:

can ctor be private?

strict private
  constructor Create;
end;

 

Yes, it can. But the problem is not in hiding your constructor. 

 

Every class in Delphi descends from base TObject class, whether you explicitly state that in class declaration or not  

 

TSingleton = class

TSingleton = class(TObject)

 

And TObject has public constructor Create. That means its every descendant and consequently every other class in Delphi has public constructor Create. Since it is public it is accessible and you cannot prevent people using it.

 

So, even if you hide constructor in descendant class, someone can write TSingleton.Create and this will not call your hidden constructor, but TObject default constructor. 

 

The only way to hide that TObject constructor is to add public constructor with same name in your class, like in example I posted. But then you again have problem with having publicly accessible constructor and people can instantiate more than single object instance. If that public constructor raises exception, then at least code will fail at runtime showing that this constructor shouldn't be used.

[Joseph MItzen 251]

On 9/6/2021 at 7:05 AM, Stefan Glienke said:

If you don't want instances, then don't make it a class - this ain't Java.

Thank you! Delphi has a method for grouping a collection of common procedures/functions together... it's called a Unit.