es geht darum, wie man eine bereits vorhandene datenstruktur - zum beispiel eine liste, einen baum oder eine elektronische schaltung - visuell repräsentieren kann. bei einfachen quick&dirty-lösungen kann man ja den anzeige-code in die struktur reinpacken, das ist aber für größere und besser strukturierte projekte nicht geeignet.
gibt es also für dieses problem verbreitete lösungen?
was ich mir vorstellen könnte, wäre, anzeigeklassen von den strukturklassen abzuleiten und dort den anzeigerest reinzupacken, oder in jede anzeigeklasse einen strukturmember reinzumachen.

etwa in der Form

class Schaltungsplan { /* ... */ };
class Graph { /* ... */ };
class Baum { /* ... */ };

void visualisiere(Schaltungsplan const &a);
void visualisiere(Graph const &a);
void visualisiere(Baum const &b);

rüdiger schrieb:

warum diese von der Datenklasse erben sollte.

ein grund wäre, dass ich in manchen fällen verwaltungscode für die struktur gleich auf die visualisierung anwenden kann. sowas wie löschen von elementen und ähnliches.

hi,

rüdiger schrieb:

warum diese von der Datenklasse erben sollte.

ein grund wäre, dass ich in manchen fällen verwaltungscode für die struktur gleich auf die visualisierung anwenden kann. sowas wie löschen von elementen und ähnliches.

Äh, würde mich doch sehr wundern, wenn die Visualisierung Elemente löscht. Ich denke mal, das die Visualisierung gut ohne die Interna der Klasse klar kommen sollte, ansonsten scheint man was mit dem Interface falsch gemacht haben.

Aber sollte es wirklich so einen Fall geben, würde ich doch wohl ein friend klar bevorzugen.

(Wir sprechen hier ja eh von privater Vererbung, oder?)

etwa in der Form

class Schaltungsplan { /* ... */ };
class Graph { /* ... */ };
class Baum { /* ... */ };

void visualisiere(Schaltungsplan const &a);
void visualisiere(Graph const &a);
void visualisiere(Baum const &b);

Finde ich etwas unflexibel, weil Veränderungen oder Erweiterungen an der Datenstruktur dann Seiteneffekte auf die zentrale Visualisierung hat. Muss man sicher von Fall zu Fall entscheiden, aber ich würde ein Interface Drawable definieren mit einer Methodensignatur zum Zeichnen/Visualisieren und jede Komponente der Datenstruktur, die darstellbar sein soll, implementiert dieses. Wer, wenn nicht die Komponenten selber, sollten wissen, wie sie auszusehen haben?

Entweder musst du Schaltungsplan::visualisiere() ändern oder du musst SchaltungsplanVisualisierer::visualisiere() ändern. Wo soll dann der Unterschied sein?

Auf interne Implementationsdetails der Datenklasse braucht die Visualisation doch sowieso nicht zu zugreifen.

Schau dir einfach das MVC Modell an, wie Jester es vorgeschlagen hat, es bietet schon sehr viele Vorteile.

Du musst so oder so die Visualisierung neu schreiben/erweitern wenn du die Daten änderst.

Eben nicht. In der von mir beschriebenen Lösung kannst Du Komponenten integrieren, ohne dabei bestehenden Code verändern zu müssen. Und gemäß MVC kannste dann alle Drawables einheitlich behandeln und in den Views darstellen. Natürlich sollte ein Drawable dabei nicht direkt in Elemente der GUI schreiben. Das ist natürlich Aufgabe des Controllers im Sinne von MVC.

In der von mir beschriebenen Lösung kannst Du Komponenten integrieren, ohne dabei bestehenden Code verändern zu müssen.

Das hast du in der MVC sowieso

moin schrieb:

Du musst so oder so die Visualisierung neu schreiben/erweitern wenn du die Daten änderst.

Eben nicht. In der von mir beschriebenen Lösung kannst Du Komponenten integrieren, ohne dabei bestehenden Code verändern zu müssen. Und gemäß MVC kannste dann alle Drawables einheitlich behandeln und in den Views darstellen. Natürlich sollte ein Drawable dabei nicht direkt in Elemente der GUI schreiben. Das ist natürlich Aufgabe des Controllers im Sinne von MVC.

Was erzählst du eigentlich, vorhin war die MVC zu unflexibel (aus welchen Grund auch immer). Jetzt willst du doch MVC machen?

Im übrigen in ähnlicher Form nachzulesen in "Entwurfsmuster" von Erich Gamma et al.

dass ganze auf die Objekte selbst zu delegieren.

Das ist ziemlich schlechtes Design. Ein Objekt soll nicht die Wollmilchsau sein, sondern Objekte sollten speziallisiert sein auf deren Aufgabenstellung.