Problem mit Komponentennamen bei abgeleiteten Formularen

[Hansa]

Bei mir sieht die Form Hierarchie z.B. so aus: TForm ->

1. Ableitung :

Damit alle Forms ISO-konform sind wird hier direkt eingebaut, dass ESC jede Form schliesst. Und die Koordinatn sollen im FormClose gespeichert und im FormCreate gelesen werden. Das ist die 1. Ableitung von TForm.

nächste Ableitungen : hier setzt die erste Verzweigung ein. Je nachdem, ob das ein reines Ausgabe-Form ist oder auch Eingaben gemacht werden können, werden nach und nach weitere Eigenschaften eingebaut. Z.b. Edit für Ku.Nr.

Mit der Einführng des Ku.Nr.-Edits im Programm-Kontext wird natürlich direkt gleich schon die Logik für das Auffinden eines Kunden eingebaut. D.h. die Taste, die die Suchfunktion aufruft, einen Suchbutton für die Maus-Bevorzuger, das Lesen der entspr. Datensätze aus der DB in den geeigneten Events etc.

Nun brauche ich z.B. eine Kunden-Statistik, eine Kundenrechnung, eine Kunden-Rechnungsliste usw. Für alle diese Fälle habe ich dann eben diverse Formulare, die einen gemeinsamen Vorfahr haben. Und sogar dieser Vorfahr weiss ja bereits von seinem entfernten Vorfahr, wie und wann er seine Koordinaten abzuspeichern hat. Es wäre Wahnsinn, all das bei jeder Form extra zu machen.

Positiver Nebeneffekt : wenn ich einen Tipfehler mache, dann ist der sehr schnell aufzufinden, weil eben je nachdem wo der sich bemerkbar macht, ziemlich schnell klar ist, wo der sein muss. Oder bei Änderungen : sagen wir mal, irgendwem gefällt die Formfarbe nicht und er will schwarz auf Lila. Jetzt hiesse es : alle Forms von Hand einzeln ändern, bei mir würde es reichen, die allererste Form dementsprechend zu ändern.

Das Letzte ist auch der entscheidende Unterschied : TForm ist TForm und Basta. Das unterliegt normalerweise nicht meinem Einfluss. Eine einzige dazwischengeschaltete Form-Ableitung (selbst wenn sie nichts macht) hebelt das komplett aus und gibt einem die volle Kontrolle (siehe Bsp. Form-Farbe). Shmia soll mal bitte irgendein Szenario nennen, wo die Form-Vererbung sich negativ bemerkbar macht.

Zumal es ja auch noch inherited; +Co. gibt. Will ich irgendetwas vom Vorfahr nicht in abgeleiteter Form haben, dann lasse ich das eben weg.

[shmia]

Zitat von Hansa:

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?

[Sir Rufo]

Zitat von shmia:

Zitat von Hansa:

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.

Ehrlich gesagt würde ich dabei aber nicht die Formularvererbung, sondern das Konzept verfluchen.
Sowas würde bei mir eine entsprechende Service-Anwendung (auf dem Server) erledigen - eigentlich sogar der DB-Server selber - auf jeden Fall aber nicht blockierend für die Anwendung.

[Hansa]

Zitat von Sir Rufo:

Ehrlich gesagt würde ich dabei aber nicht die Formularvererbung, sondern das Konzept verfluchen. Sowas würde bei mir eine entsprechende Service-Anwendung (auf dem Server) erledigen - eigentlich sogar der DB-Server selber - auf jeden Fall aber nicht blockierend für die Anwendung.

Die angesprochene Sache geht ja mit

Zitat:

ON DELETE CASCADE

Das muss die DB eben wissen.

Das hat also nichts mit vererbten Formularen zu tun. Wichtiger ist das :

Zitat:

TForm <--- TFormWithPos (Formular, dass sein Position speichern/laden kann)
TForm <--- TLogForm (Formular mit Logausgabe)

Was aber, wenn man beides will?

Was schadet es dem LogForm, seine Koordinaten zu speichern ?? Sofern die LogAusgabe nur eine Form betrifft muss das vererbt werden ??

Es handelt sich um einen Vorgang, den man unterbrechen kann (wenn man will).

[shmia]

Zitat von Hansa:

Was schadet es dem LogForm, seine Koordinaten zu speichern ?? Sofern die LogAusgabe nur eine Form betrifft muss das vererbt werden ??
Es handelt sich um einen Vorgang, den man unterbrechen kann (wenn man will).

Und was würde passieren, wenn wir eine weitere Funktionalität hinzufügen würden?
Zum Beispiel sollen auf bestimmten Formularen Benutzerrechte durchgesetzt werden.
Der angemeldete Benutzer hat bestimmte Rechte (oder er hat sie nicht).
Entsprechend den Rechten werden dann bestimmte Controls dekativiert oder unsichtbar geschaltet.
Wie sieht dann wohl die Hierarchie der Form-Klassen aus?
Tiefe Hierarchien führen in die Sackgasse; sie erschweren Änderungen und verstosen gegen das Single Responsibility Prinzip.

Ich weiss nicht, ob man einem erfahrenen Programmierer wie Dir noch etwas beibringen kann; ich hab's zumindest versucht.
http://www.youtube.com/watch?feature...GU7aH8OA#t=44s

[idefix2]

Wenn ich von TForm einen Formulartyp ableite, von dem ich dann alle meine Formulare ableite, hindert mich nichts daran, öfters benutzte Funktionalitäten in dieses abgeleitete Formular zu integrieren - gegebenenfalls mit entsprechenden published boolean Schaltern.

Tiefe Hierarchien sind gar nicht nötig, aber zumindest eine vorgeschaltete Hierarchiestufe, in der ich alle Erweiterungen einbauen kann, die sich im Laufe des Projekts ergeben, ist sehr sinnvoll und spart in der Regel viel Arbeit.

Natürlich kann man für jede Zusatzfunktionalität eine neue nicht-visuelle Komponente erstellen, die man auf die Formulare klatscht - Nur wenn ich eine Menge Funktionalität habe, die in allen oder den meisten Formularen vorhanden sein soll, ist das unnötig mühsam, unübersichtlich und auch fehleranfällig: irgend einem neugeschriebenen Formular fehlt dann irgend eine Funktionalität, weil der Programmierer auf die entsprechende Komponente vergessen hat, und das fällt vielleicht erst auf, wenn die neue Programmversion schon an viele Kunden verteilt worden ist - oder man muss in den Routinetests vor der Auslieferung für jedes einzelne Formular das Vorhandensein aller Features, die automatisch vorhanden sein sollten und bei Vererbung auch automatisch vorhanden sind, separat überprüfen, was den Testaufwand wieder beträchtlich erhöht. Es könnte auch ein Programmierer in einem der bestehenden Formulare eine dieser nichtvisuellen Komponenten irrtümlich löschen - einmal an der Entfernen-Taste ankommen und so eine Komponente ist ohne Rückfrage und ohne dass es sonst weiter auffällt, weg - dann ist in der Folge das Verhalten in dem einen Eingabeformular inkonsistent.

[shmia]

Zitat von idefix2:

... aber zumindest eine vorgeschaltete Hierarchiestufe, in der ich dann alle Erweiterungen einbauen kann.

Ich glaube nicht, dass du das Single Responsibility Prinzip verstanden hast; du kannst doch nicht alles Mögliche in eine (Form-)Klasse einbauen.
Das ergibt den kleinen Bruder eines sog. God Objekts.
Hast du schon mal Testgetriebene Entwicklung (TDD) praktiziert? Oder vielleicht mal Unit-Tests mit DUnit geschrieben?
Falls ja, dann wirst du gemerkt haben, dass man solche grossen Klassen, die alle möglichen Funktionalitäten beherbergen (weils anscheinend so bequem ist) nicht mehr richtig testen kann.

Ich kann nur empfehlen: Lest das Buch "Clean Code" von Robert C. Martin (download PDF) und schaut euch Videos über SOLID auf Youtube an.