Eine Variable für alle Units zugänglich machen?

[xZise]

Wie kann ich am einfachsten eine Variable (string) mit einem Text versehen, und die dann für alle Units zugänglich zu haben. Dabei sollte es vor dem Createprozedur geschehen.
Nun kann ichs auch nicht im Create machen, weil die anderen Formulare auch diese Variable benötigen.
Und eigentlich ist es ja unsinnig mehrere Variablen und mehrere sets der Variablen durchzuführen...

Deshalb muss das irgendwie (wahrscheinlich) in der Projektdatei stehen... nur wie mache ich da Variablen "public"?

PS: Möglichst einfach :P

[3_of_8]

Wie wärs mit dem initialization-Abschnitt?

[xZise]

Wovon?
Der Projektdatei?

Sind die Variablen dann auch für die Units zugänglich?

[3_of_8]

Nein. Der initialization-Abschnitt einer Unit deiner Wahl. Alle Units, die diese Unit einbinden, können auf die Variable zugreifen. Eine Projektdatei hat keine Initialization und soweit ich weiß kann eine Unit auch nicht auf Variablen der Projektdatei zugreifen.

[Pfoto]

Zitat:

Nun kann ichs auch nicht im Create machen, weil die anderen Formulare auch diese Variable benötigen.

Ich mach es so:

Es gibt eine Unit, die dient als Schnittstelle für globale Daten
der Anwendung und auch von PlugIns.
Sie besitzt ein Objekt "Host", wo Variablen, bestimmte Methoden,
Datenbanktabellen etc. vorhanden sind.

In dieser Unit gibt es auch schon eine Variable für das Objekt,
sie steht direkt darunter (also ähnlich wie bei den TForms).

Nun kann ich dieses Objekt in z.B. der ersten Unit erstellen lassen,
die während des Projekt-Starts erzeugt wird.

ich kann dann von allen Units auf dieses globale Objekt und auf dessen
Variablen / Methoden etc. zugreifen.

Normal sind ja globale Variablen in der OOP verpöhnt, aber
nicht aus Prinzip, sondern eher dann, wenn man's übertreibt und nicht
mehr durchblick...


Gruß
Pfoto

[omata]

Zitat:

Zitat von Pfoto

Normal sind ja globale Variablen in der OOP verpöhnt, aber
nicht aus Prinzip, sondern eher dann, wenn man's übertreibt und nicht
mehr durchblick...

Danke für diesen Versuch/Hinweis.

@xZise: Auf Unit-Globale Variablen würde ich verzichten, ist ganz schlechter Stil und wirklich unschön.

Gruss
Thorsten

[Khabarakh]

@Pfoto: Würdest du da mit dem Singleton-Pattern nicht besser fahren? Gleiche (globale-Variablen-freie :)) Empfehlung an xZise ;) .

[DGL-luke]

*Finger zum Kreuz erhebe* Geh weg mit deiner .Net-Versuchung, Khabarakh! Zumindest wüsste ich nicht, wos in D.W32 ein Singleton-Pattern gibt...

[Pfoto]

Zitat:

@Pfoto: Würdest du da mit dem Singleton-Pattern nicht besser fahren?

Wenn es um's Prinzip geht, hast du mit dem Singleton-Pattern recht!
Obwohl ich davon weiß, ist es mir leider noch nicht so präsent,
dass ich es bereits wie selbstverständlich einbaue...

Aber welchen echten praktischen Vorteil hätte es wenn ich davon
ausgehen könnte, das während des Programmablaufs *nicht* unbeabsichtigt
mehrere Instanzen erstellt werden?
Ist es dann wirklich nur eine Sache aus Prinzip?

Gruß
Pfoto

[3_of_8]

@DGL-Luke: Ein Singleton Pattern ist nichts .NET-Spezifisches. Man kann es auch in Delphi implementieren, auch wenn ich finde, das gehört eher in die GC Sprachen wie Java, C# und PHP.

[Khabarakh]

Zitat:

Zitat von Pfoto

Aber welchen echten praktischen Vorteil hätte es wenn ich davon
ausgehen könnte, das während des Programmablaufs *nicht* unbeabsichtigt
mehrere Instanzen erstellt werden?

Das ist für mich persönlich gar nicht der springende Punkt des Pattenrs, sondern eher der zentrale Zugriff auf die einzige Instanz. Bei deiner Lösung würde mich stören, dass ich nicht sicher sein kann, dass das Objekt schon erstellt wurde (da es eben in einer fremden Unit initialisiert werden muss) und ich die globale Variable natürlich jederzeit ändern könnte. Echte Kritikpunkte sind das natürlich nicht, eher einfach Frage des Geschmacks bzw. wie du sagtest des Prinzips, und das heißt bei mir "hide information where possible" ;) .

@DGL-Luke: :cry: :gruebel:

Delphi-Quellcode:

type
   TFFA = class
   strict private
      class var FInstance: TFFA;
      constructor InternalCreate;
      class function GetInstance: TFFA; static;
   public
      class property Instance: TFFA read GetInstance;
      constructor Create;
   end;


{ TFFA }

constructor TFFA.Create;
begin
   raise SingletonException.Create(TFFA);
end;

class function TFFA.GetInstance: TFFA;
begin
   if not Assigned(FInstance) then
      FInstance := TFFA.InternalCreate;
   Result := FInstance;
end;

constructor TFFA.InternalCreate;
begin
   ...
end;

Genausogut mit Eager Creation möglich. Dasimho einzig Unschöne ist der öffentliche Konstruktor, aber TObject.Create ist nunmal dämlicherweise public.

[add] In ähnlicher Weise natürlich auch mit Versionen < 2006 möglich. [/add]

[add id="1"]
@3/8: :gruebel:
Für das Singleton-Pattern wird man in jeder Sprache eine globale Variable bzw. ein statisches Feld benötigen und solche sind in den allermeisten Sprachen Garbage-Collection-Roots, also nicht wegfegbar bis zur Terminierung.
[/add]

[3_of_8]

:lol: Frag mich nicht, wie ich auf GC gekommen bin. Eigentlich meinte ich Sprachen mit einer Klassenstruktur, die das Verstecken eines Konstruktors erlauben.

[Khabarakh]

Achso, ok :lol: .

Hätt ich an deiner Stelle jetzt auch behauptet :mrgreen:

BTT: Die Sache mit dem Konstruktor würde ich nicht so eng sehen. Das Prinzip der Sichtbarkeit ist klasse, aber soll keine Idiotenabwehr sein. Wer nicht hören will, muss bei "TSingleton.Create" eben fühlen :mrgreen: .

[xZise]

Ähm ich habe zwar kein Plan wegen den Singleton Pattern...
Aber ich hätte es jetzt auch ungefähr so gemacht, nur das das Problem ist, dass ich die Instanz irgendwie "weitergeben" muss :D

[DGL-luke]

naja... dann kannst du auch die Klasse weitergeben. Abstrakte Klasse TSingleton mit der class procedure GetInstance.

@Khabarakh: Bist du dir sicher, dass das so hinhaut? immerhin wirft der konstruktor, und der wird in getinstacne aufgerufen...

[3_of_8]

Zitat:

Zitat von Khabarakh

Achso, ok :lol: .

Hätt ich an deiner Stelle jetzt auch behauptet :mrgreen:

BTT: Die Sache mit dem Konstruktor würde ich nicht so eng sehen. Das Prinzip der Sichtbarkeit ist klasse, aber soll keine Idiotenabwehr sein. Wer nicht hören will, muss bei "TSingleton.Create" eben fühlen :mrgreen: .

Prinzipiell soll man ja nach dem "Böser User"-Prinzip programmieren, also von einem Benutzer ausgehen, der alles falsch macht, was er falsch machen kann. Daher ist Delphi hier leicht ungeeignet.

[Khabarakh]

@DGL-Luke: Uppsala, das nennt man fehlgeschlagenes Refactoring :stupid: . Muss natürlich ein Aufruf des privaten Konstruktors sein.

Zitat:

Zitat von 3_of_8

Prinzipiell soll man ja nach dem "Böser User"-Prinzip programmieren, also von einem Benutzer ausgehen, der alles falsch macht, was er falsch machen kann.

"Böser User" = "Böser Programmer"? Nun, bei Otto-Fatal-Bürger muss man Gande vor Recht walten lassen, aber den Bösen des eigenen Faches wird auf die Fingerchen geklopft, ist doch perfekt :zwinker: .

[3_of_8]

Ja, in gewisser Weise ist ja der Programmierer, der die Unit einbindet, ein User der Unit.

Wenn ich eine Unit/mehrere Units schreibe, interpretiere ich den Programmierer, der es später verwendet, als User. Und dieser User könnte ja ein DAU sein, und der soll möglichst wenig falsch machen können.

[xZise]

Zitat:

Zitat von DGL-luke

naja... dann kannst du auch die Klasse weitergeben.

Problem => Ich müsste es nach "create" machen ;)