Programmierdogmata

[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.

[p80286]

Zitat von sx2008:

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.

Auch wenn ich noch nicht restlos von der Überflüssigkeit globaler Variablen/Constanten.. überzeugt bin, so ###### kann doch kein Mensch/Programmierer sein?
Spätestens beim Einsatz der zweiten Unit, wird das doch so komplex, daß man eine saubere Schnittstelle braucht und sich nicht auf "das steht da irgendwo in der..." zurückziehen kann.

Eben darum sollten ja auch die Daten von der Oberfläche getrennt sein.

Ich bin viel zu faul (je weniger Aufwand für ein Ergebnis desto besser) als daß ich mir so etwas antuen würde.

Gruß
K-H

[Uwe Raabe]

Zitat von p80286:

Auch wenn ich noch nicht restlos von der Überflüssigkeit globaler Variablen/Constanten.. überzeugt bin, so ###### kann doch kein Mensch/Programmierer sein?

Meistens entsteht so etwas schleichend. Am Anfang waren die einzelnen Adressfelder vielleicht noch einzelne globale Variablen (das Programm stammt vielleicht noch aus Turbo Pascal 1.0 Zeiten). Dann fasst man das als Record zusammen, später als Klasse. Dann kommt eine Unit nach der anderen dazu und man hat gerade überhaupt keine Zeit das richtig umzubauen. Irgendwann ist dann der nötige Aufwand schon happig, weil man so viele Units anfassen muss.

Manchmal muss man sich einfach selbst zwingen, solche Dinge rechtzeitig zu bereinigen. Unterm Strich spart man dann doch wieder Zeit.