Problem mit Komponentennamen bei abgeleiteten Formularen

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

Zitat von Sir Rufo (Beitrag 1160670)

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:

Zitat von Sir Rufo (Beitrag 1160670)

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:

Zitat von shmia (Beitrag 1160760)

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

Was ? :shock: 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

Delphi-Quellcode:

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

Delphi-Quellcode:

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" 8-)

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

Zitat von Hansa (Beitrag 1160778)

gleiches Aussehen : betrifft Koordinaten, Fonts

=> Factory verwenden.

Zitat:

Zitat von Hansa (Beitrag 1160778)

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

=> Frames verwenden

Zitat:

Zitat von Hansa (Beitrag 1160778)

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:

Zitat von Hansa (Beitrag 1160778)

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:

Zitat von Hansa (Beitrag 1160778)

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

Application.OnMessage

Zitat:

Zitat von Hansa (Beitrag 1160778)

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:

Zitat von Hansa (Beitrag 1160778)

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

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:

Zitat von himitsu (Beitrag 1160779)

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

[idefix2]

Zitat:

Zurecht wie ich meine. Wie auch immer die abgelegten Formulare aussehen mögen, es ist doch meistens etwas dabei was man nicht haben will.

Es lebe der Fundamentalismus. Break und exit sind böse, with ist urböse, für die Verwendung von goto ist Steinigung die adäquate Stafe, und neuerdings ist Vererbung auch schon ganz schlecht.

Wenn ich bestimmte Features einheitlich in allen meinen Formularen haben will, dann ist die Ableitung meiner Formulare von einem Vorfahr, der alle diese Features beinhaltet, die ADÄQUATE Vorgangsweise. natürlich gibt es auch andere Möglichkeiten, man kann Frames definieren, man kann Helper-Komponenten auf alle Formulare ziehen, man kann sich mit einer Factory behelfen etc. etc. Alle diese Möglichkeiten würde ich auch ins Auge fassen, wenn es in Delphi nicht zum Glück die einfachste und beste Lösung, nämlich die Vererbung, geben würde.

Zitat:

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.

Wenn ich das will, macht es sicher Sinn, so eine Komponente zu verwenden. Wenn ich in einer einfachen Anwendung einfach nur die Formularposition beim Schliessen in ein Ini-File schreiben und beim Öffnen wieder aus dem Ini-file lesen will, gibt es kein vernünftiges Argument, die entsprechenden Vierzeiler nicht direkt im Code des Formulars zu integrieren. Aber auch wenn ich eine eigene Komponente verwende, kann ich den Aufruf der entsprechenden Funktionalität in mein zu vererbendes Urformular einbauen. Dass ein Formular weiss, wo es zuletzt zugegangen ist und dort auch wieder aufgeht, verstösst bestimmt auch nicht gegen das Allerwichtigste, nämlich das Single Responsability Prinzip.

[Sir Rufo]

Zitat:

Zitat von idefix2 (Beitrag 1160860)

Wenn ich in einer einfachen Anwendung einfach nur die Formularposition beim Schliessen in ein Ini-File schreiben und beim Öffnen wieder aus dem Ini-file lesen will, gibt es kein vernünftiges Argument, die entsprechenden Vierzeiler nicht direkt im Code des Formulars zu integrieren. Aber auch wenn ich eine eigene Komponente verwende, kann ich den Aufruf der entsprechenden Funktionalität in mein zu vererbendes Urformular einbauen. Dass ein Formular weiss, wo es zuletzt zugegangen ist und dort auch wieder aufgeht, verstösst bestimmt auch nicht gegen das Allerwichtigste, nämlich das Single Responsability Prinzip.

Doch, das verstösst dagegen ... das Formular sollte nur wissen, wo es sich befindet - logisch - und wem es dieses mitteilen soll, bzw. umgekehrt wen es fragen soll. Wo und wie sich das gemerkt wird ist nicht dia Aufgabe des Formulars ;)

Die Vererbung zu benutzen um sich das Leben einfacher zu machen aber gleichzeitig hinten die Vasen wieder zu zertrümmern ist nicht konsequent.

Schreibt man sich dafür eine entsprechende Logik (Unit) kann man diese hervorragend wiederverwenden, per Unit-Test prüfen und braucht sich keine Gedanken mehr darum machen.

[himitsu]

Dennoch kann man diese Funktionalität in das Formular einbauen.
Und sei es nur die Schnittstelle dafür.

Also z.B. wie beim Popupmenü oder dem CustomHint, ein Property, wo man sonstwas anhängen könnte und dessen Aufruf an den entsprechenden Stellen integriert wurde.
Oder man baut den Aufruf überall direkt ein, zu einer globalen Klasse/Funktion, welche dann das Speichern übernimmt.

[idefix2]

Natürlich lässt sich jede Aufgabe nahezu beliebig weiter zerlegen. Dann habe ich eine Unit, die weiss, dass Daten in ein ini-File geschrieben werden sollen, die ruft dann eine unit auf, die ihr sagt, wie die Ini-Datei heissen soll, danach eine Unit, die weiss, welche Daten geschrieben werden sollen etc.