Problem mit Komponentennamen bei abgeleiteten Formularen

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

[Hansa]

Zitat von shmia:

Es gibt aber nur ganz wenig was alle Formulare teilen können.

Was ? Da werden Logfiles, Benutzerrechte etc. angeführt, um eine Form nicht zu vererben. Ich frage mich da, was das mit einer Form an sich zu tun hat ?

Und das "nur ganz wenig", was Formulare gemeinsam brauchen, das stellt sich folgendermassen dar :

gleiches Aussehen : betrifft Koordinaten, Fonts, diverse Controls (z.B. Schliessen-Button u.ä.)Auch speichern des aktuellen Standes.

gleiche Bedienung :

Tastatur : ein Tasten-Bedienung ! Wie gesagt : ISO-konform und nicht nach M$-"Standard". Also Esc zum schliessen und nicht Alt-F4. Ähnliches gilt für Tab/Shift-Tab, Suchtaste muss immer dieselbe sein etc. Betrifft OnKeyDown,OnKeyPress + Co.

Maus : selbes Spielchen. Die Mausevents können zentral implementiert werden.

Dann gehts noch um Speicherfreigaben und anderes. In meiner eigenen Ur-Form gibts auch noch ein OnClose mit Action := caFree; Besser, so was ist automatisch schon eingebaut.

Und sollte irgendwo was nicht passen, dann besteht die Erhöhung dieser "Flexibilität" nur darin, das inherited; wegzulassen. Dann kann man ja alles wieder einfach neu bzw. anders definieren.

Allerdings muss ich es mit Marco Cantu halten. In Köln auf den Delphi-Tagen habe ich länger mit dem diskutiert. Wir mussten leider feststellen, dass "even experienced Developers don't know, how to use repository, perhaps they simply ignore that"

[himitsu]

Formvererbung?

Komisch, das erinnert mich irgendwie an die OOP und das Vererben von billigen Klassen/Komponenten.



Ja OK, das ist natürlich ganz schlim und sowas macht keiner.
Prozeduren gehören in eine Unit und nicht in eine Klasse.
Vererbter Code ist schlecht, denn ändert man mal was am Vorfahren, dann sind auch gleich alle Nachfahren futsch ... darum besser garnicht erst vererben und jedesmal alles neu schreiben.

[shmia]

Zitat von Hansa:

gleiches Aussehen : betrifft Koordinaten, Fonts

=> Factory verwenden.

Zitat von Hansa:

diverse Controls (z.B. Schliessen-Button u.ä.)

=> Frames verwenden

Zitat von Hansa:

Auch speichern des aktuellen Standes.

Dafür gibt es Komponenten wie z.B. TFormStorage. Diese Komponenten können jedes Property des Formulars und aller darauf enthaltenen Komponenten in die Registry oder eine Ini-Datei speichern und auch wieder laden.

Zitat von Hansa:

Tastatur : ein Tasten-Bedienung ! Wie gesagt : ISO-konform und nicht nach M$-"Standard". Also Esc zum schliessen und nicht Alt-F4. Ähnliches gilt für Tab/Shift-Tab, Suchtaste muss immer dieselbe sein etc. Betrifft OnKeyDown,OnKeyPress + Co.

=> globale Änderungen lassen sich zentral im Application.OnMessage Eventhandler erledigen (z.B. Return-Taste soll bewirken, dass zum nächsten Control gesprungen wird)

Zitat von Hansa:

Maus : selbes Spielchen. Die Mausevents können zentral implementiert werden.

Application.OnMessage

Zitat von Hansa:

Dann gehts noch um Speicherfreigaben und anderes. In meiner eigenen Ur-Form gibts auch noch ein OnClose mit [DELPHI]Action := caFree;[/DELPH]

Das darf man aber nur dann machen, wenn man die globale Variable, die Delphi zu jeder Form-Klasse autom. ablegt auskommentiert so dass man sie nicht benützen kann.

Zitat von Hansa:

Allerdings muss ich es mit Marco Cantu halten. ... "even experienced Developers don't know, how to use repository, perhaps they simply ignore that"

Zurecht wie ich meine. Wie auch immer die abgelegten Formulare aussehen mögen, es ist doch meistens etwas dabei was man nicht haben will.
Das Ableiten von Formularen in der Objektablage mag ja für ein Login-Form oder ein About-Form noch in Ordnung gehen.
Die Formulare in der Objektablage werden durch die Versionverwaltung nicht erfasst; das führt zu Problemen wenn man den Sourcecode weitergibt.
Wer immer nur auf dem gleichen Rechner arbeitet der kennt das Problem nicht.
Verwenden, also Kopieren von Formularen aus der Objektablage ist dagegen problemlos.

Zitat von himitsu:

... das Vererben von billigen Klassen/Komponenten.
Ja OK, das ist natürlich ganz schlim und sowas macht keiner.

Bitte diskutieren und nicht lästern; sonst können wir das hier gleich bleiben lassen.