Entscheidungshilfe Klassenaufbau

[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