Entscheidungshilfe Klassenaufbau

[haentschman]

Hallo alle...

ich komme mir mal wieder vor wie eine Frau im Schuhladen...

Was ich möchte:
- "InlineEditor" auf Basis TForm
- über 20 verschiedene Objekttypen und damit Editoren

Was ich gemacht habe:
- Basis Form
- abgeleitete Klasse für Objekt X von BasisForm
- Klasse bekommt beim Create das Objekt mit
- Klasse erzeugt die Controls und legt diese in TObjectList ab
- Klasse stellt die Daten dar
- von außen wird nur Position (Top/Left) gesetzt
- usw...


Jetzt habe ich gemerkt, daß wenn ich für jeden Objekttyp eine eigene Klasse ableite vieles doppelt habe. Es gibt ja auch Gemeinsamkeiten die ich nicht im Vorfahr ablegen kann. Ich wollte aber auch eine Lösung, daß sich der Editor selbst "organisiert" . Quasi Daten übergeben und um nix kümmern. Dann nur je nach Status (OK / Abbruch) die Daten über die ObjectList holen oder verwerfen.

1. Möglichkeit:
- für jeden Objekttyp eine Klasse

2. Möglichkeit:
- eine Klasse
- anhand des Objekttypes entscheiden welche Controls erstellt werden (ObjectList)

3. Möglichkeit:
- eine Klasse mit der Basis
- alles andere von außen regeln (Controls / Daten)

Welche Vorgehensweise würdet ihr empfehlen ?

Danke

Nachtrag:
es sind auch Controls vom Typ Combobox enthalten. Wenn man das Objekt selbst "entscheiden" lassen würde müßte man auch dem Editor mitteilen wo er die Daten herbekommt. Das ist eher nicht optimal oder ?

[r2c2]

Ich bin mir nicht ganz sicher, ob ich dich richtig versteh:

Zitat von haentschman:

Was ich möchte:
- "InlineEditor" auf Basis TForm
- über 20 verschiedene Objekttypen und damit Editoren

OK, ich denke, das hab ich noch verstanden. Du hast 20 verschiedene Objekttypen und willst für jeden nen InlineEditor haben, mit den man jeweils ein Objekt bearbeiten kann.

Zitat:

Was ich gemacht habe:
- Basis Form
- abgeleitete Klasse für Objekt X von BasisForm
- Klasse bekommt beim Create das Objekt mit
- Klasse erzeugt die Controls und legt diese in TObjectList ab
- Klasse stellt die Daten dar
- von außen wird nur Position (Top/Left) gesetzt
- usw...

OK, hört sich gut an. Hätt ich wahrscheinlich auch so gemacht.

Zitat:

Jetzt habe ich gemerkt, daß wenn ich für jeden Objekttyp eine eigene Klasse ableite vieles doppelt habe.

Dann hast du wie immer zwei Möglichkeiten: Delegation und Vererbung.

Zitat:

Es gibt ja auch Gemeinsamkeiten die ich nicht im Vorfahr ablegen kann.

Die da wären? Da versteh ich nicht so ganz, was dein Problem ist. Leider ist das wohl die zentrale Stelle...

Zitat:

Ich wollte aber auch eine Lösung, daß sich der Editor selbst "organisiert" . Quasi Daten übergeben und um nix kümmern.

Da versteh ich nicht, warum das nicht gehen sollte. Würde ich auch wollen sowas. Und ich sehe noch keinen Grund, was da nicht funktionieren soll.

Zitat:

Dann nur je nach Status (OK / Abbruch) die Daten über die ObjectList holen oder verwerfen.

Da versteh ich nicht, wo auf einmal die ObjectList herkommt.

Zitat:

1. Möglichkeit:
- für jeden Objekttyp eine Klasse

2. Möglichkeit:
- eine Klasse
- anhand des Objekttypes entscheiden welche Controls erstellt werden (ObjectList)

Kommt drauf an. Dazu müsste man wissen, wie stark sich die Objekttypen unterscheiden. Je stärker, desto eher getrennte Klassen.

Zitat:

3. Möglichkeit:
- eine Klasse mit der Basis
- alles andere von außen regeln (Controls / Daten)

Da bin ich mir nicht sicher, ob ich dich richtig verstehe. Du willst von außen die Controls deines InlineEditors händisch befüllen? Würde ich definitiv von abraten. Das ist ganz schlecht. Inhaltskopplung urgs... Du kennst die Geschichte vom Paperboy und die Brieftasche?

Zitat:

es sind auch Controls vom Typ Combobox enthalten. Wenn man das Objekt selbst "entscheiden" lassen würde müßte man auch dem Editor mitteilen wo er die Daten herbekommt. Das ist eher nicht optimal oder ?

Da weiß ich gar nicht, was du meinst.

mfg

Christian

[haentschman]

Danke für das ausführliche Statement...

Zitat:

Zitat:
Es gibt ja auch Gemeinsamkeiten die ich nicht im Vorfahr ablegen kann.
Die da wären? Da versteh ich nicht so ganz, was dein Problem ist. Leider ist das wohl die zentrale Stelle...

...die Button Events der Form werden als Event weitergereicht. Somit bräuchte jede abgeleitete Klasse die entsprechenden Prozeduren.

Zitat:

Zitat:
Dann nur je nach Status (OK / Abbruch) die Daten über die ObjectList holen oder verwerfen.
Da versteh ich nicht, wo auf einmal die ObjectList herkommt.

...die Objectlist wo die Controls drinstehen. Je Editor eine eigene.

Zitat:

Zitat:
1. Möglichkeit:
- für jeden Objekttyp eine Klasse

2. Möglichkeit:
- eine Klasse
- anhand des Objekttypes entscheiden welche Controls erstellt werden (ObjectList)
Kommt drauf an. Dazu müsste man wissen, wie stark sich die Objekttypen unterscheiden. Je stärker, desto eher getrennte Klassen.

... ich habe mich für getrennte Klassen entschieden wobei ich noch eine "dazwischengeschaltet" habe

TKlasse1: TForm
TKlasse2: TKlasse1 // Event entgegennehmen, Liste Controls erzeugen/ freigeben ... Gemeinsamkeiten
TKlasseEditorObject: TKlasse2 //managed die benötigten Controls und die Anzeige

Zitat:

Zitat:
es sind auch Controls vom Typ Combobox enthalten. Wenn man das Objekt selbst "entscheiden" lassen würde müßte man auch dem Editor mitteilen wo er die Daten herbekommt. Das ist eher nicht optimal oder ?
Da weiß ich gar nicht, was du meinst.

...die Comboboxen müssen dynamisch mit DB Daten gefüllt werden. Entweder von außen oder der Editor kennt das "DB Framework" um sich die Liste der Daten selbst zu holen. Wäre nicht das Problem ihm das über eine Property bekannt zu machen.

[r2c2]

Irgendwie hast du das Talent alles so zu erklären, dass ich es nicht verstehe. Oder es ist schon spät...

Zitat von haentschman:

Zitat:

Zitat:
Es gibt ja auch Gemeinsamkeiten die ich nicht im Vorfahr ablegen kann.
Die da wären? Da versteh ich nicht so ganz, was dein Problem ist. Leider ist das wohl die zentrale Stelle...

...die Button Events der Form werden als Event weitergereicht. Somit bräuchte jede abgeleitete Klasse die entsprechenden Prozeduren.

Auch Events sind vererbbar. Kannst du alles in der Basisklasse machen und musst nix replizieren. Ich versteh dein Problem nicht.

Zitat:

Zitat:

Zitat:
Dann nur je nach Status (OK / Abbruch) die Daten über die ObjectList holen oder verwerfen.
Da versteh ich nicht, wo auf einmal die ObjectList herkommt.

...die Objectlist wo die Controls drinstehen. Je Editor eine eigene.

- von außen solltest du niemals auf interne Objektlisten zugreifen
- auch intern wüsste ich nicht, warum du über die Liste gehen willst. Kannst du nicht private Felder nehmen?

Zitat:

... ich habe mich für getrennte Klassen entschieden wobei ich noch eine "dazwischengeschaltet" habe

TKlasse1: TForm
TKlasse2: TKlasse1 // Event entgegennehmen, Liste Controls erzeugen/ freigeben ... Gemeinsamkeiten
TKlasseEditorObject: TKlasse2 //managed die benötigten Controls und die Anzeige

Bedeutet der Doppelpunkt hier ungewöhnlicherweise "ist abgeleitet von"? Wenn ja: Was tut Klasse1? (BTW: ich hoffe mal, die heißt nicht wirklich so.)

Zitat:

Zitat:

Zitat:
es sind auch Controls vom Typ Combobox enthalten. Wenn man das Objekt selbst "entscheiden" lassen würde müßte man auch dem Editor mitteilen wo er die Daten herbekommt. Das ist eher nicht optimal oder ?
Da weiß ich gar nicht, was du meinst.

...die Comboboxen müssen dynamisch mit DB Daten gefüllt werden. Entweder von außen oder der Editor kennt das "DB Framework" um sich die Liste der Daten selbst zu holen. Wäre nicht das Problem ihm das über eine Property bekannt zu machen.

Fänd ich nicht gut. Damit koppelst du deine GUI-Klasse direkt an die DB (und womöglich noch an ein konkretes DB-Layout). Verpass deinem InlineEditor ne Property, die du von außen befüllen kannst. Die Property reicht dann die Daten an die ComboBox weiter...

mfg

Christian

[haentschman]

Moin...

war bestimmt nur spät

Zitat:

Auch Events sind vererbbar. Kannst du alles in der Basisklasse machen und musst nix replizieren. Ich versteh dein Problem nicht.

Klar sind die Events vererbbar. Jede abgeleitete Klasse muß die aber entgegennehmen und hat damit jeweils die gleichen Proceduren dazu. Das habe ich jetzt in TKlasse2 als Gemeinsamkeit.
die heißen nicht so... hast du schon richtig gesehen.

Zitat:

auch intern wüsste ich nicht, warum du über die Liste gehen willst. Kannst du nicht private Felder nehmen?

... ich hatte mich für die Liste entschieden weil die Anzahl der Controls unterschiedlich ist, ich mir keine Namen ausdenken muß und die Controls von außen über eine Property zugänglich sind.

Zitat:

Wenn ja: Was tut Klasse1?

...Klasse1 ist nur die Form mit den Buttons OK/Abbrechen. Macht nix an Logik außer dem Event wegschicken wenn ein Button gedrückt wurde.

Zitat:

Verpass deinem InlineEditor ne Property, die du von außen befüllen kannst.

...auch kein Problem eine Liste zu übergeben.

Danke... jetzt ist die Richtung schon klarer

[sx2008]

Wozu brauchst du das ganze Zeug überhaupt?

Hier mal ein Beispiel, dass immer wieder aufkommt:
Eine Software druckt irgendwelche spezielle Berichte, Rechnungen, Artikellisten usw.
Es gibt dann Kunden, die bestimmte Dinge im Layout geändert haben wollen.
Irgendjemand kommt dann auf die glorreiche Idee:
"Wäre es nicht cool, wenn der Kunde selbst seine Reports frei gestalten könnte?"
Es gibt auch Report Generatoren die sog. "End-User Report Designer" enthalten.
Aber was soll ich sagen:
Es funktioniert nicht!!
Die Kunden verstehen nicht wie der Designer funktioniert, sie haben keine Ahnung von Bändern
und weshalb bestimmte Dinge technisch nicht möglich sind, usw.
Ok, sie können ein Feld verschieben, die Breite oder den Font verändern, aber das war's dann auch.

Das Gleiche trifft auch auf Designer für Formulare zu.
Hinter jedem Formular sitzt eine "Bussines-Logik".
Das Formular bedient sich dieser Logik.
Wenn das Formular vom Endkunden frei verändert werden kann und mit der relativ starren Bussines-Logik interagieren soll, dann geht das in aller Regel schief.
Was mich dann wieder zur Frage am Anfang bringt.

[haentschman]

Zitat:

Wozu brauchst du das ganze Zeug überhaupt?

...endlich mal ne einfache Frage

ich habe in meiner Anwendung haufenweise Listen von Daten (intern Objekte). Diese Daten werden in Listviews visualisiert und bearbeitet. Ich will einen "InlineEditor" der sich anhand des Objekttyps selbst verwaltet (visuell/Daten)...siehe Bild 1. Beitrag

...das wars...

[r2c2]

Zitat von haentschman:

Zitat:

Auch Events sind vererbbar. Kannst du alles in der Basisklasse machen und musst nix replizieren. Ich versteh dein Problem nicht.

Klar sind die Events vererbbar. Jede abgeleitete Klasse muß die aber entgegennehmen und hat damit jeweils die gleichen Proceduren dazu.

Das kannst du doch schon in der Basisklasse tun, oder? Ich hab immer noch das Gefühl, dass ich dich nicht richtig versteh. Poste vielleicht mal ein bisschen Code. Das sollte mir helfen, dich zu verstehen.

Zitat:

Das habe ich jetzt in TKlasse2 als Gemeinsamkeit.

Also in ner gemeinsamen Basisklasse. Gut. Genau so. Die einzig sinnvolle Variante, oder? Besondere Nachteile fallen mir hier auch nicht ein.

Zitat:

Zitat:

auch intern wüsste ich nicht, warum du über die Liste gehen willst. Kannst du nicht private Felder nehmen?

... ich hatte mich für die Liste entschieden weil die Anzahl der Controls unterschiedlich ist, ich mir keine Namen ausdenken muß und die Controls von außen über eine Property zugänglich sind.

Bezeichnerwahl ist normalerweise die falsche Stelle um faul zu sein. Das geht i.d.R. nach hinten los. Lieber hier 5 min. länger nachdenken und später nerviges Debugging sparen.

Zitat:

Zitat:

Wenn ja: Was tut Klasse1?

...Klasse1 ist nur die Form mit den Buttons OK/Abbrechen. Macht nix an Logik außer dem Event wegschicken wenn ein Button gedrückt wurde.

Warum musst du dann Klasse1 und Klasse2 trennen? Geht das nicht in einer Klasse?

mfg

Christian

[haentschman]

Hallo...

Zitat:

Das kannst du doch schon in der Basisklasse tun

Zitat:

Warum musst du dann Klasse1 und Klasse2 trennen? Geht das nicht in einer Klasse?

...ich könnte auch das was in Klasse2 steht in die Form nehmen. Da könnte man die Events z.B. sparen. Dort wollte ich aber nur visuelle Sachen haben. Von daher etwas komplizierter...

Zitat:

Bezeichnerwahl ist normalerweise die falsche Stelle um faul zu sein. Das geht i.d.R. nach hinten los. Lieber hier 5 min. länger nachdenken und später nerviges Debugging sparen.

...nun ja, die Anzahl der Controls ist eher übersichtlich (meistens 2 oder 3). Das einzig nervige an der Liste ist die Casterei