Globale Variablen

[tjp]

Deshalb: Du magst die Methode bescheuert finden, aber so ungewoehnlich ist sie vielleicht gar nicht.

Ich habe etliche Bücher und Artikel zum Thema Design Patterns und das in verschiedenen Programmiersprachen, in keinem wird das so gemacht. Der Hauptgrund dürfte sein, daß hier eine Methode für zwei diametral verschiedene Dinge genutzt wird, und dies als gegen den OOP-Grundsatz verstößt, daß man Methoden immer für eine klar definierte Aufgaben benutzt.

Ich bleib dabei: das ist schlechtes Design und man sollte es nicht so lösen. Leider kennt Objective-C keine Klassenattribute wie Smalltalk. So nebenbei ist dein Bespiel nicht Thread-safe, wie das Apple Beispiel.

 

[Peter Maurer]

Ich bleib dabei: das ist schlechtes Design [...]

Das steck' ich gerne ein. Fuer mich ist es halt bequem so.

So nebenbei ist dein Bespiel nicht Thread-safe [...]

Danke fuer die Warnung, die mich allerdings nicht so 100%ig ueberrascht. Zum Glueck macht das da, wo ich es so mache, nix.

 

[Amin Negm-Awad]

a) Üblicherweise wird ein Singleton gar nicht reinstantiert.

b) Eine globale Variable ist definitv nicht besser gekapselt, sondern schlechter.

c) Es liegt daher genau das Gegenteil eines Verstoßes "gegen den OOP-Grundsatz" (was immer auch das sein mag) vor. Wer globale Variablen hingegen präferiert, sprich wohl auch von "dem OOP-Grundsatz". (Wobei ich immer noch nicht weiß, was das sein soll.)

d) Singletons sind auch (nicht nur) zur Vermeidung von globalen Variablen erfunden worden. Daher ist die Implementierung von Singletons über Globals ziemlich selbstblödsinnig.

e) Globale Variablen Verstoßen gegen den Grundgedanken der Verbindung von Code und Daten.

f) Singletons als lokale Membervariable einer Klassenmethode sind garantiert einzigartig und bilden daher Klassenaatribute von Smalltalk nach. Globale Variablen tun dies gerade nicht. Daher ist es das Gegenteil der Lösung dieses Problems.

g) Globals sind nicht von hause aus thread-safe, lokale Variablen auch nicht. Das hat nichts mit der Problematik dieser beiden Möglichkeiten zu tun. Man muss beide thread-safe machen oder eben nicht. Wie man es braucht.

h) Die Methode erledigt genau eine definierte Aufgabe: Gib mir den Singleton. Auch die Methode -sumOperand:toOther: nimmmt Parameter und erledigt daher genau eine definierte Aufgabe.

 

[Peter Maurer]

Üblicherweise wird ein Singleton gar nicht reinstantiert.

Ja. In den meisten Faellen (mir faellt grade ein QTMovie-Platzhalter-Cache ein; und da kann man mehrere Threads eh vergessen) leere ich auch bloss ein Array oder so. Aber das aendert wohl an tjps Kritik nix, weder das fuer mich zugegebenermassen nur bedingt interessante Prinzip noch die Thread-Sicherheit betreffend.

 

[Amin Negm-Awad]

Du bekommst auch bei Globals keine Thread-Safety kostenlos. Der Aufwand dürfte sogar größer sein.

Diese Problematik des Threadings hat weder mit der einen noch mit der anderen Lösung etwas zu tun und vor allem: Nichts mit diesem Thread. (Was für ein schönes Wortspiel *g*)

 

[Peter Maurer]

Ich kann's mir nicht verkneifen: Eben.

 

[Amin Negm-Awad]

Ich kann's mir nicht verkneifen: Eben.

Wir sehen das exakt gleich.

 

[tjp]

a) Üblicherweise wird ein Singleton gar nicht reinstantiert.

Es geht hauptsächlich darum, daß man das Singleton gezielt destruieren kann.

b) Eine globale Variable ist definitv nicht besser gekapselt, sondern schlechter.

Eine globale Variable wird nicht verwendet. Lerne endlich mal C.

 

[Amin Negm-Awad]

a) Die Dekonstruktion des Singletons ist in beiden Fällen dasselbe Problem. Auch in dem Apple-Beispiel findet sich kein Code zur Dekonstruktion. Zudem: Jede Dekonstrution bedeutet automatisch die Möglichkeit der Neukonstruktion, nämlich bei erneuter Benutzung des entsprechenden Getters.

b) Sie ist global, auch wenn sie static deklariert wird. Global sind alle Variablen, die außerhalb eines Blockes stehen.

Etwa:
"static wird standardmäßig bei der Definition globaler Variablen verwendet. Die beiden Variablen im Programmbeispiel unten, (count und road), haben beide das Attribut static."
http://home.fhtw-berlin.de/~junghans/cref/CONCEPT/storage_class.html


c) ?

d) ?

f) ?

g) ?

h) ?