Problem mit Komponentennamen bei abgeleiteten Formularen

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

[idefix2]

Code:

du kannst doch nicht alles Mögliche in eine (Form-)Klasse einbauen.

Das solltest Du versuchen, Embarcadero zu erklären Die haben nämlich alles mögliche in ihre TForm-Klasse eingebaut.

Und Du würdest Dich schön bedanken, wenn Du für jede einzelne Funktionalität, die im TForm integriert ist, eine extra Komponente auf die Form legen müsstest.

[Sir Rufo]

@shima

wo soll denn jetzt genau das Problem mit den vererbten Formularen sein und wo verstösst da was gegen CleanCode?

Niemand hat hier behauptet ein GodFatherFormular zu bauen, dass alle nur irgendwie erdenklichen Funktionen enthalten soll, die evtl. nur irgendein Formular benutzt.

Aber was spricht dagegen alle Formulare von einer BasisForm abzuleiten in der das implementiert ist, was alle Formulare in der Anwendung benötigen?

Jetzt kommen x weitere Formulare, die einzelne Datensätze bearbeiten, die alle die Funktionen Save, Reset und Cancel beherrschen müssen. Warum sollte ich da nicht ein EditBasisFormular anlegen von dem ich dann alle Edit-Formulare ableite?
Sollte man tatsächlich dann für alle x Formulare die Funktionalitäten (Buttons) coden?
Das ist dann aber nicht wirklich DRY.

Jetzt kommen noch x Listen-Formulare, die müssen alle die Funktionalität Bearbeiten, Drucken, Exportieren, Löschen, etc. enthalten.

Und wo du schon von UnitTests sprichst, die Funktionalität selber sollte ja eh nicht im Formular sitzen, sondern nur von diesem aufgerufen werden.
Also selbst für das Speichern der Form-Position sollte der Code nicht in der Basis-Form liegen, sondern lediglich von dieser aufgerufen werden.

[Hansa]

Zitat von Sir Rufo:

Also selbst für das Speichern der Form-Position sollte der Code nicht in der Basis-Form liegen, sondern lediglich von dieser aufgerufen werden.

Hä ? Wieso soll die nicht da liegen ?

[idefix2]

Es kommt wohl darauf an, wie komplex das gehandhabt wird. Wenn die Formularpositionen z.B. einfach in einer ini-Datei gespeichert werden, spricht wohl nichts dagegen, das direkt im der Form-Unit zu erledigen.

Bei komplexeren Anwendungen, bei denen wir die Formularpositionen, Farben und Schriftarten Benutzer- und Bildschirmgrössenabhängig zusammen mit einer Reihe von anderen erweiterten Formulareigenschaften in eigenen Tabellen der Anwendungsdatenbank speichern, haben wir das in eine eigene Unit ausgelagert. Datenbankzugriffe und dergleichen haben in einer generischen TMyForm-Unit wirklich nichts verloren.

[Bummi]

@Hansa

ich mache es es zwar auch nicht so aber einfache Aufrufe wie Store/RestoreBoundsRect
ließen sich so durch Unittausch/umdeklaration oder bedingte Kompilierung recht einfach auf ein anderes Storage verlegen.

[shmia]

Zitat von Sir Rufo:

Aber was spricht dagegen alle Formulare von einer BasisForm abzuleiten in der das implementiert ist, was alle Formulare in der Anwendung benötigen?

Gute Frage.
Es gibt aber nur ganz wenig was alle Formulare teilen können.
Sollte es eine visuelle Gemeinsamkeit vor einigen Formularen geben (z.B. Panel mit Ok- und Abbrechen-Button) dann lässt sich das viel flexibler mit Frames handhaben.

Der Baukasten der OOP beinhaltet mehr als nur Vererbung!
Es gibt daneben auch Composition, Dependency Injection und Abstract Factorys.
Wenn ich z.B. eine Factory benütze um bestimmte Dinge in allen Formularen einzustellen anstatt abzuleiten dann bin ich einfach freier bei zukünftigen Änderungen.
Ein Klasse abzuleiten bedeutet immer auch eine gewisse Zementierung der Methoden.
Die Basisklasse kann kaum noch geändert werden weil unter Umständen hunderte Formulare davon abhängen.
Da aber Formulare immer auch Hotspots für Veränderungen sind ist es wichtig, dass man hier Vererbung vermeidet um die Möglichkeiten zur Veränderung offen zu halten.
Die Klasse TForm ist schon von sich aus richtig "fett"; es gibt sehr viele Methoden und Properties.
Solche Klassen sollte man nicht zusätzlich durch weitere Ableitungen aufblasen.
Kleine Klassen die nach dem Baukastenprinzip zusammengesetzt werden lassen mehr Freiheit für Veränderungen.

Zitat von Sir Rufo:

Also selbst für das Speichern der Form-Position sollte der Code nicht in der Basis-Form liegen, sondern lediglich von dieser aufgerufen werden.

Richtig - der Code gehört in eine eigene Klasse. (Single Responsibility Prinzip)