AGB  ·  Datenschutz  ·  Impressum  







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

Problem mit Komponentennamen bei abgeleiteten Formularen

Ein Thema von fkf · begonnen am 5. Apr 2012 · letzter Beitrag vom 9. Apr 2012
Antwort Antwort
Seite 2 von 3     12 3   
shmia

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

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 00:04
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?
Andreas
  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
 
#12

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 01:25
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.
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
Hansa

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

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 03:03
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).
Gruß
Hansa

Geändert von Hansa ( 7. Apr 2012 um 03:07 Uhr)
  Mit Zitat antworten Zitat
shmia

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

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 20:24
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
Andreas
  Mit Zitat antworten Zitat
idefix2

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

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 21:59
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.

Geändert von idefix2 ( 7. Apr 2012 um 22:51 Uhr)
  Mit Zitat antworten Zitat
shmia

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

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 22:54
... 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.
Andreas
  Mit Zitat antworten Zitat
idefix2

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

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 23:04
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.
  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
 
#18

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 23:25
@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.
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
Hansa

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

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 23:43
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 ?
Gruß
Hansa
  Mit Zitat antworten Zitat
idefix2

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

AW: Problem mit Komponentennamen bei abgeleiteten Formularen

  Alt 7. Apr 2012, 23:58
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.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

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 16:47 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