Programmierdogmata

[SubData]

Zitat:

Zitat von Sir Rufo (Beitrag 1210523)

Zitat:

Zitat von SubData (Beitrag 1210520)

Naja... Wenn man es auf Haarspalterei auslegt, dann kann eine Anwendung, die nicht mindestens eine
globale Variable beinhaltet gar nicht existieren ;-)
Oder zumindest in den seltensten Fällen...

Warum? Nur weil Borlemba da schlampt und kein echtes Singleton (Application) davon macht?

Siehst, du nennst den Grund ja schon selbst ;-)

Edit sagt: Man kann sich drüber streiten... Ich verteufel globale Variablen nicht pauschal, es gibt einige Situationen,
in denen die praktisch und nützlich sind, aber man muss eben sehr gewissenhaft damit arbeiten und sie nicht an
jeder Stelle, an der es gerade möglich ist, in den Quellcode hauen.
Ich habe auch schon sinnige Anwendungsfälle für Do With gesehen, und teilweise auch schon Situation, in denen
man mit einem Goto arbeiten könnte (KÖNNTE!, nicht MUSS!)

Regeln sind dafür da, das sie auch einfach mal gebrochen werden müssen, sonst würde keine Innovation existieren,
aber man muss eben immer abwägen, ob es wirklich einen Vorteil bringt und man sich bzw. dem nächsten Programmierer
damit Arbeit spart, oder ob man in dem Moment einfach zu faul ist, um es richtig zu programmieren...

Ich denke, dass 90% des sauberen Codes einfach damit zusammenhängt, dass man beim Entwickeln nachdenkt und nicht
gerade irgendwas reinhackt, was zufällig passt, bzw. sich Quellcode von den verschiedensten Stellen zusammen klaut.

[Sir Rufo]

Zitat:

Zitat von SubData (Beitrag 1210539)

Zitat:

Zitat von Sir Rufo (Beitrag 1210523)

Zitat:

Zitat von SubData (Beitrag 1210520)

Naja... Wenn man es auf Haarspalterei auslegt, dann kann eine Anwendung, die nicht mindestens eine
globale Variable beinhaltet gar nicht existieren ;-)
Oder zumindest in den seltensten Fällen...

Warum? Nur weil Borlemba da schlampt und kein echtes Singleton (Application) davon macht?

Siehst, du nennst den Grund ja schon selbst ;-)

Niemand bezweifelt die Existenz von globalen Variablen, ich bezweifle aber die Sinnhaftigkeit derselben.
Und Application als globale Variable habe ich auch nicht zu verantworten und kann ich auch nicht ändern (außer kein Delphi mehr zu benutzen).

Ich bin für meinen Code primär und für die 3rd-Party-Libs sekundär verantwortlich und primär gibt es bei mir keine globalen Variablen (nein ich lösche die automatisch erzeugten Form-Variablen nicht - das ist mir zu affig, aber ich benutze diese auch nicht).

@p80286

Für beides gibt es sinnvolle(re) Alternativen. Zumal für das Loggen sich eine Klasse empfiehlt, die in ihrer Instanz den Dateinamen verwaltet.

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1210546)

Für beides gibt es sinnvolle(re) Alternativen. Zumal für das Loggen sich eine Klasse empfiehlt, die in ihrer Instanz den Dateinamen verwaltet.

Manchmal sind es nur Formulierungen, die zum Nachdenken anregen.
Mal sehen Wie ich die "Globalen" ausrotten kann.

Gruß
K-H

[Elvis]

Zitat:

Zitat von Sir Rufo (Beitrag 1210523)

Warum? Nur weil Borlemba da schlampt und kein echtes Singleton (Application) davon macht?

Singletons sind fast globale Variablen.
Haben ja auch fast alle Probleme, die generell mit globalem State auftauchen. Eine Ausnahme, die mir gerade in den Sinn kommt, wären immutable Objekte. Da sollte es keine Probleme mit Threads und anderen Nebenläufigkeiten geben. Aber auch die können per DI oder schlicht als Parameter durchgeschliffen werden.

[SubData]

Ich sehe trotzdem kein Problem darin eine globale Thread-Variable anzulegen, die ggf. nötige Referenzen auf Sessions
oder das Eltern-Thread-Objekt beinhaltet. Ob da nun eine Klasse, eine Referenz, ein Record oder sonstwas hinter
steckt ist in dem Fall erstmal egal. Das ist in meinen Augen eine saubere Lösung und sie ermöglicht es an jeder Stelle
im Thread darauf zuzugreifen, ohne, dass ich sie in jeder Klasse durchschleifen bzw. sichtbar machen muss.

[Sir Rufo]

Zitat:

Zitat von Elvis (Beitrag 1210550)

Zitat:

Zitat von Sir Rufo (Beitrag 1210523)

Warum? Nur weil Borlemba da schlampt und kein echtes Singleton (Application) davon macht?

Singletons sind fast globale Variablen.
Haben ja auch fast alle Probleme, die generell mit globalem State auftauchen. Eine Ausnahme, die mir gerade in den Sinn kommt, wären immutable Objekte. Da sollte es keine Probleme mit Threads und anderen Nebenläufigkeiten geben. Aber auch die können per DI oder schlicht als Parameter durchgeschliffen werden.

Eben nur fast ... ;)

Das Böse an globalen Variablen ist doch, dass diese eingesetzt werden, wo es sich absolut nicht um etwas Globales handelt und durch die Verwendung bekomme ich Abhängigkeiten die die Wiederverwendbarkeit nicht zulässt.

Wie schon festgestellt wurde, gibt es aber durchaus die Anforderung nach einer einzigen globalen Instanz, die naturbedingt auch nur einmal pro Anwendung vorkommen kann (Application, Screen, etc.).

Nimmt man hier aber jetzt eine globale Variable, so kann diese Variable auch übereschrieben werden, ohne dass die abhängigen Teile darüber informiert werden.

Gerade im Thread-Umfeld muss auch bedacht werden, dass eine globale Variable eben nicht threadsafe ist. Somit ist das in so einem Umfeld der vorgeplante Schuss ins Knie.

[Furtbichler]

Zitat:

Zitat von Mathematiker (Beitrag 1210531)

1. und 4. stimmen hier wohl nicht. Also bleiben noch 2. und 3.
Was wird wohl auf mich zutreffen?

Hab dich nicht so. Dann bist Du eben nicht faul und machst alles richtig.

Zum Thema 'globale Variablen'. Meine Meinung: Einfach nicht verwenden. Wenn schon, dann in ein Singleton-Pattern packen. Und pro Singleton eine Kiste Bier/Brause für die Entwickler. Man muss das wirklich begründen und wenn alle einverstanden sind, dann ist die Welt in Ordnung.

[sx2008]

Es gibt noch zwei Aspekte die hier noch nicht angesprochen wurden:

1.) Unit-Tests
Wenn man mit Software Geld verdienen möchte und Softwareentwicklung im grösserem Rahmen betreibt, dann braucht man Unit-Tests.
Das bedeutet aber auch dass die Software so geschrieben werden muss, dass sie sich überhaupt testen lässt.
Globale Variablen und Singletons wirken sich extrem störend auf die Testbarkeit von Klassen und Funktionen aus.
Das gleiche gilt auch wenn die Benutzeroberfläche und die tiefere Logik nicht getrennt sind.

2.) grosse Anwendungen (> 500 Delphi Units)
Bei grossen Anwendungen können kleine Änderungen in den Anforderungen grosse Probleme verursachen wenn die Architektur nicht sauber ist.
Kleines Beispiel aus der Praxis:
Eine Anwendung aus dem Bereich der Logistik soll "mandantenfähig" gemacht werden; d.h. es soll mit mehreren Mandanten statt bisher nur einem umgehen können.
Das Problem war aber dass die zum Mandanten gehörenden Daten in einem globalen Objekt gespeichert wurden

Delphi-Quellcode:

var
  AdrMandant : TAdresseMandant;  // enthält Name, Anschrift, Tel, EMail, Fax, Kontoverbindung, Umsatzsteuernr,...

Auf diese globale Objekt greifen aber hunderte Units zu.
Wenn man die Mandantendaten ändert weil man z.B. eine Rechnung drucken möchte, dann hat das globale Auswirkungen auf die ganze Anwendung.
Letztendlich wurde die globale Variable vernichtet und vielen Klassen wird jetzt das Mandantenobjekt von Aussen übergeben.
Diese Umbauarbeiten haben hunderte Stunden an Arbeit gekostet und sich über ein dreivirtel Jahr hingezogen.

Beispiel 2:
Ein Kunde wollte den Rechnungsdruck nicht über die Benutzeroberfläche starten, sondern über TCP/IP aus einem anderen System anstossen.
Leider ist aber die Benutzeroberfläche, die Datenbankzugriffe und die Logik auf einem Formular so verzahnt, dass man den Rechnungsdruck nur per Mausklick starten kann.
Bis heute hat sich daran nicht geändert, weil sich niemand traut an dem komplexen Gebilde etwas zu ändern.

[SubData]

Zitat:

Zitat von Sir Rufo (Beitrag 1210557)

[...]

Wie schon festgestellt wurde, gibt es aber durchaus die Anforderung nach einer einzigen globalen Instanz, die naturbedingt auch nur einmal pro Anwendung vorkommen kann (Application, Screen, etc.).

Nimmt man hier aber jetzt eine globale Variable, so kann diese Variable auch übereschrieben werden, ohne dass die abhängigen Teile darüber informiert werden.

[...]

Man kann theoretisch jeden Mist programmieren, man kann auch Konstanten überschreiben.
Aber wenn ein Entwickler auf die Idee kommt eine globale Variable wie Application zu überschreiben,
dann gehört er gehörig gesteinigt und daran ist nicht die globale Variable schuld.

Gerade Application sehe ich aber eher als gute globale Variable. Wie gesagt, wenn jemand anfängt
sowas zu überschreiben, dann ist nicht die Variable schuld.

[Sir Rufo]

Zitat:

Zitat von SubData (Beitrag 1210563)

Zitat:

Zitat von Sir Rufo (Beitrag 1210557)

[...]

Wie schon festgestellt wurde, gibt es aber durchaus die Anforderung nach einer einzigen globalen Instanz, die naturbedingt auch nur einmal pro Anwendung vorkommen kann (Application, Screen, etc.).

Nimmt man hier aber jetzt eine globale Variable, so kann diese Variable auch übereschrieben werden, ohne dass die abhängigen Teile darüber informiert werden.

[...]

Man kann theoretisch jeden Mist programmieren, man kann auch Konstanten überschreiben.
Aber wenn ein Entwickler auf die Idee kommt eine globale Variable wie Application zu überschreiben,
dann gehört er gehörig gesteinigt und daran ist nicht die globale Variable schuld.

Gerade Application sehe ich aber eher als gute globale Variable. Wie gesagt, wenn jemand anfängt
sowas zu überschreiben, dann ist nicht die Variable schuld.

Weil es ja auch ach so schwer ist statt

Delphi-Quellcode:

var
  Application : TApplication;

einfach

Delphi-Quellcode:

function Application : TApplication;

implementation

var
  _Application : TApplication;

function Application : TApplication;
begin
  Result := _Application;
end;

zu schreiben. (Die Erzeugung von TApplication hab ich jetzt raus gelassen).

Das kann man aber auch wirklich keinem zumuten :roll: