Problem mit Komponentennamen bei abgeleiteten Formularen

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

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