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.