Shmia soll mal bitte irgendein Szenario nennen, wo die Form-Vererbung sich negativ bemerkbar macht.
In einen Warenwirtschaftssystem (2-Tier Design) werden Rechnungen verteilt über mehrere Tabellen verbucht.
Irgendwann müssen die alten Rechnungen und alle abh. Daten auch mal gelöscht werden.
Also gibt es dazu ein Formular.
Das Problem ist nur solange der Löschvorgang läuft ist das Programm blockiert.
Ausserdem muss das Löschen nachts laufen und nicht während der Arbeitszeit.
Also soll das Formular mit allen seinen Abhängigkeiten in ein neues Projekt verpflanzt werden.
Diese Wartungsanwendung läuft dann z.B. zeitgesteuert direkt auf einem Server.
Wenn das betreffende Formular abgeleitet ist (womöglich sogar mehrfach) dann höre ich schon die
WTFs die der Programmierer von sich gibt.
Die tiefe Vererbungshierarchie zieht einen ganzen Rattenschwanz von Abhängigkeiten nach sich, die man in dem neuen Projekt nicht brauchen kann.
Vererbung ist eben mit Vorsicht zu geniesen und es gibt auch andere Techniken im
OOP.
http://www.clean-code-developer.de/F...ance-FCoI.ashx
http://en.wikipedia.org/wiki/Composi...er_inheritance
http://de.wikipedia.org/wiki/Liskovs...tutionsprinzip
Um zum Beispiel die Formularposition in einer Inidatei oder Registry zu speichern, sollte man den Code nicht in einem Basisformular ablegen. Stattdessen gibt es eine eigene Klasse (abgeleitet von TComponent) die diese Dienstleistung für das Formular erbringt.
Andere Formulare benötigen z.B. die Ausgabe von Log-Info die dann in einer Logdatei gesammelt werden oder über's Netzwerk verschickt werden.
Auch das gehört nicht in eine Basisklasse eine Formulars.
Mal angenommen man würde die beide Funktionalitäten mit Vererbung lösen wollen:
Code:
TForm <--- TFormWithPos (Formular, dass sein Position speichern/laden kann)
TForm <--- TLogForm (Formular mit Logausgabe)
Was aber, wenn man beides will?