AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Problem mit Komponentennamen bei abgeleiteten Formularen
Thema durchsuchen
Ansicht
Themen-Optionen

Problem mit Komponentennamen bei abgeleiteten Formularen

Ein Thema von fkf · begonnen am 5. Apr 2012 · letzter Beitrag vom 9. Apr 2012
Antwort Antwort
Seite 3 von 3     123   
Benutzerbild von Bummi
Bummi

Registriert seit: 15. Jun 2010
Ort: Augsburg Bayern Süddeutschland
3.470 Beiträge
 
Delphi XE3 Enterprise
 
#21

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 8. Apr 2012, 00:01
@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.
Thomas Wassermann H₂♂
Das Problem steckt meistens zwischen den Ohren
DRY DRY KISS
H₂ (wenn bei meinen Snipplets nichts anderes angegeben ist Lizenz: WTFPL)
  Mit Zitat antworten Zitat
shmia

Registriert seit: 2. Mär 2004
5.508 Beiträge
 
Delphi 5 Professional
 
#22

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 8. Apr 2012, 16:49
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.


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

Geändert von shmia ( 8. Apr 2012 um 17:15 Uhr)
  Mit Zitat antworten Zitat
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#23

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 8. Apr 2012, 20:04
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"
Gruß
Hansa

Geändert von Hansa ( 8. Apr 2012 um 20:07 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#24

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 8. Apr 2012, 20:16
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.
$2B or not $2B
  Mit Zitat antworten Zitat
shmia

Registriert seit: 2. Mär 2004
5.508 Beiträge
 
Delphi 5 Professional
 
#25

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 8. Apr 2012, 22:59
gleiches Aussehen : betrifft Koordinaten, Fonts
=> Factory verwenden.
diverse Controls (z.B. Schliessen-Button u.ä.)
=> Frames verwenden
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.
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)
Maus : selbes Spielchen. Die Mausevents können zentral implementiert werden.
Application.OnMessage
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.

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.


... 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.
Andreas
  Mit Zitat antworten Zitat
idefix2

Registriert seit: 17. Mär 2010
Ort: Wien
1.027 Beiträge
 
RAD-Studio 2009 Pro
 
#26

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 9. Apr 2012, 19:04
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.

Geändert von idefix2 ( 9. Apr 2012 um 19:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#27

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 9. Apr 2012, 19:37
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.
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#28

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 9. Apr 2012, 19:48
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.
$2B or not $2B
  Mit Zitat antworten Zitat
idefix2

Registriert seit: 17. Mär 2010
Ort: Wien
1.027 Beiträge
 
RAD-Studio 2009 Pro
 
#29

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 9. Apr 2012, 21:46
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.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 3 von 3     123   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:18 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz