[Tutorial] Singletons in Delphi

[stoxx]

in neueren Delphi-Versionen würde man aber statt der Variablen in der Unit eine class var benutzen ..

Delphi-Quellcode:

TBundeskanzler = class
private
  class var Bundeskanzler : TBundeskanzler;

end

;

[Meflin]

Zitat:

Zitat von TBx

ähm, räusper ...
das widerspricht sich total. Von einem Singelton kann es nicht mehr als eine Instanz geben, sonst wäre es ja keines .....

Der Witz am Singleton ist doch, dass man es eben doch leicht so abändern kann, dass man mehrer Instanzen zulassen kann. Ansonsten könnte man ja auch einfach alles klassenseitig implementieren.

[sx2008]

Singletons sollte man durchaus kritisch sehen :warn:
Letztendlich handelt es sich dabei um globale Objekte; also im Prinzip das Gleiche wie globale Variablen.
Globale Variablen und Singletons machen uns Programmierer das Leben schwer, weil sie unangenehme Seiteneffekte hervorrufen.

Wer Englisch versteht sollte sich unbedingt mal dieses Video The Clean Code Talks - "Global State and Singletons" auschauen.
Es könnte die Meinung über Singletons grundlegend ändern...

[alzaimar]

Ich finde das Tutorial gut, aber besser wäre es, wenn es sich noch an die Styleguidelines bezüglich Nomenklatur halten würde.
Felder beginnen mit 'f', keine 'ungarische Notation' bzw. Verklausulierung des Datentyps, und Underscores sollten vermieden werden.

Zum Google-Video fällt mir nur ein, das es natürlich wichtig ist, auf die Gefahren hinzuweisen, die sich hinter solchen Praktiken verbergen, aber man muss schon die richtigen Schlüsse daraus ziehen.
Die Dogmen der 'modernen' Softwareentwicklung sind wirklich sinnvoll:
1. Globale Variablen sind böse. Mein Programm ist eine globale Variable, ebenso alle Formulare und Datenmodule.
2. Goto's sind böse. Mein Programm besteht letztendlich aus (fast) nichts anderem.
3. Singletons sind böse. Neben dem Programm verzichte ich damit auf Caches, Dictionaries, Logger, Drucker, Festplatten und Bildschirme etc.. Oh, und letztendlich auf den User.

Also ich weiss nicht. Ich LIEBE es, gegen Dogmen zu verstoßen. Und verdiene mein Geld damit. Allerdings auch nur deshalb, weil ich nicht inflatorisch gegen Dogmen verstoße.

Ach so, bei jedem Argument gehört ein :stupid: und ein :mrgreen: dahinter, :zwinker:

Zurück zum Tutorial: Ich würde folgenden Gegenvorschlag machen:

Delphi-Quellcode:

unit SingletonUnit;
interface
type
  TSingleton = class
  protected
  // Verbergen der dem Singleton-Prinzip widersprechenden Methoden, so kann man dann nicht mal 'aus Versehen'
  // ein Singleton freigeben. 
    constructor Create;
    destructor Destroy;
    procedure Free;
  public
  // Es ist nur das sichtbar, was das Singleton kann
    procedure PublicMethod();
  end;

// Automatische 'Lazy initialization' 
function Singleton: TSingleton;

implementation
var
  SingletonInstance: TSingleton;

function Singleton: TSingleton;
begin
  if SingletonInstance = nil then
    SingletonInstance := TSingleton.Create;
  Result := SingletonInstance;
end;

{ TSingleton }

constructor TSingleton.Create;
begin
  inherited;
end;

destructor TSingleton.Destroy;
begin
  inherited;
end;

procedure TSingleton.Free;
begin
  inherited Free;
end;

procedure TSingleton.PublicMethod;
begin
  // Do Something;
end;

initialization
  SingletonInstance := nil;
finalization
  SingletonInstance.Free;
end.

[MisterNiceGuy]

Hi, danke für eure Hinweise :)

@mr2: InterlockedCompareExchange funktioniert nicht mit Create als 2. Parameter. Hast du das getestet?

[schlecki]

Hallo,

nochmal zum Problem mit dem Konstruktor: Es kann nichts mehr versteckt werden, was bereits in einer Elternklasse veröffentlich wurde. Man kann dann zwar nicht genau diesen Konstruktor aufrufen, trotzdem ist es möglich, eine Instanz dieser Klasse zu erzeugen.

Besser ist es, wenn man soetwas macht:

Delphi-Quellcode:

TSingleton = class(TObject)
private
  constructor _Create();
public
  constructor Create();
end;

{...}

constructor TSingleton.Create();
begin
  raise Exception.Create('Use TSingleton.getInstance!');
end;

constructor TSingleton._Create();
begin
  inherited Create;
  {...}
end;

Auf diesem Weg ist es nicht mehr möglich, eine Instanz dieser Klasse ohne den eigenen Konstruktor zu erzeugen.

[alzaimar]

Soweit ich das überschaue, bekommt man soetwas nicht bullet-proof hin, d.h. es ist immer möglich, das jemand mutwillig das Konzept unterminiert, z.B. durch Typecasting. Aber ich denke, darum muss man sich nicht kümmern, das ist imho etwas spitzfindig, denn wir entwickeln Klassen und Konzepte nicht für unsere Feinde, sondern Kollegen.

Es geht doch eher darum, das man ein Singleton nicht mehrfach instantiiert oder versehentlich freigibt, weil man das Konzept nicht begriffen hat, und nicht, das man es unter allen umständen verbietet. Dann würde ich -glaube ich- einen Sentinel schreiben, der alle Instanzen außer der ersten gnadenlos abschießt und den (End-)Benutzer mit einer entsprechenden Meldung verwirrt. Natürlich könnte man auch das wieder umgehen usw. Also, WTF.

[schlecki]

Darum gehts hier doch gar nicht. Wenn man nicht weiß, dass es sich um ein Singleton handelt, bekommt man es auch nicht mit, wenn man es mal mit TSingleton.Create aufruft.
Bei mir kommt eben ein Hinweis, wie man die Klasse richtig verwendet. Auch unter Kollegen kann so ein Hinweis ganz nett sein, bevor man ev. stundenlang den Fehler sucht, warum die Konfiguration oder sowas nicht korrekt geschrieben wird.

Edith sagt:

Hast du eigentlich schon mal folgendes probiert?

Delphi-Quellcode:

type
  TSingleton = class(TObject)
  private
    constructor Create; 
  end;

und dann in einer anderen Unit(!):

Delphi-Quellcode:

var
  s: TSingleton;
begin
  s := TSingleton.Create;
end;

Das kompiliert ganz wunderbar, nur der aufgerufene Konstruktor ist der von TObject. Wunderbar, was? Und das alles ganz ohne Typecast.

Und nochwas, ich versuche, meine Sachen immer so sicher wie möglich zu machen. Warum? Vielleicht habe ich ja eine Bibliothek oder Komponente erstellt, die ich mit Sourcecode weiterverteilen möchte. Und dann macht man es den Benutzern doch wesentlich einfacher, die eigene Arbeit korrekt zu verwenden.

[alzaimar]

Echt? Ich hab nur in der Codevervollständigung keinen Vorschlag mehr für Create gefunden, glaub ich jedenfalls. :gruebel:
Wenn das gar nicht stimmt und nichts bringt, ist es natürlich für die Katz.

Kennst Du denn eine absolut saubere Implementierung eines Singletons in Delphi? Ich glaub, das geht gar nicht.
Delphi ist eben keine moderne Programmiersprache, in C# ist es mit einigen wenigen Zeilen Code getan.

[schlecki]

Zitat:

Zitat von alzaimar

Kennst Du denn eine absolut saubere Implementierung eines Singletons in Delphi? Ich glaub, das geht gar nicht.
Delphi ist eben keine moderne Programmiersprache, in C# ist es mit einigen wenigen Zeilen Code getan.

Eine absolut saubere Implentierung kenn ich auch nicht. Aber im Normalfall reicht die Version mit der Exception im Create.