Ich frage mich gerade, wie ich in einer GUI Anwendung die Objekthirarchie gestalte und stelle fest, daß ich kein vernünftige Regel kenne.

Also, da sei eine Anwendung. Die Awendung besteht im Prinzip ausfolgenden Objekten (hier dargestellt sind die Referenzen/Zeiger von einem Object zum anderen, denn die Klassen sind komponiert, nicht vererbt, da überall die hat-ein Beziehung zutrifft):

Application -> Desktop -> MainWindow -> ProjectWindow =>> VieleWidgets
                      |              -> PropertyWindow =>> VieleWidgets
                      |              -> AboutDialog =>> VieleWidgets
                      |
                       -> Splashscreen =>> VieleWidgets

Jetzt geht es darum eine neue Klasse "Project" einzuführen. Die Anwendung soll maximal ein Objekt dieses Typs per Zeiger halten können. Auch hier natürlich hat-ein Beziehung. Das Objekt soll gelöscht und wieder erzeugt werden können (darum der Zeiger). Nun soll das MainWindow und sein untergeordnetes ProjectWindow Zugriff auf das Project erhalten. Also würde ich sagen, ich lege den Project-Zeiger in das ProjectWindow. Das würde schön in die Hierarchie passen und ich bräuchte keine Rückwärtszeiger oder Rückwärtsreferenzen.
Da allerdings abzusehen ist, daß auch andere Tochter-Fenster des MainWindows (z.B. das PropertyWindow) Zugriff auf das Project benötigen werden, ist es besser, den Zeiger auf das Project ins MainWindow zu legen. Ich müßte dann allerdings den beiden untergordneten Fenstern (ProjectWindow und PropertyWindow) eine Referenz auf das Project mitgeben (z.B. bei ihrer Konstruktion). Das wäre vermutlich ok.

Andererseits würde ich instinktiv aber nicht dem folgenden Satz zustimmen: "Das Hauptfenster hat ein Project" sondern ich würde vielmehr sagen "Die Anwendung hat ein Project". Schließlich müßte/könnte ein potentielle Kommandozeilen-Variante des gleichen Programms auch völlig ohne GUI ein Projekt verwenden können. Darum hat das Project meiner Meinung nach nichts in einer GUI-Klasse verloren. Ich würde darum dazu neigen, den Project-Zeiger in die Applikation zulegen.
Das allerdings würde bedeuten, daß das ProjectWindow und PropertyWindow sich über drei Rückwärtzeiger zum Projekt durchhangeln müßten. Das ist wiederlich. Alternative zum Letzteren wäre, von Application über Desktop über MainWindow eine Referenz auf einen Zeiger zu übergeben, die dann letztendlich in ProjectWindow und PropertyWindow verwendet werden könnte. Das heißt, daß ich in vier ohnehin schon umfangreichen Konstruktoren eine Referenz auf einen Zeiger (auf ein Project) immer vielfach durchreichen müßte, das scheint mir sehr aufwändig.

Kann mir irgendjemand ein wenig helfen meine Gedanken zu ordnen?

Ansonsten müßte jede Klasse einen Owner besitzen, der auf das übergeordnete Objekt zeigt.
Du kanst dann ja Helperfunktionen definieren, welche die Mehrfachrückwärtsverkettung erledigen.

Soll es denn mehrere Applikationen geben, ansonsten könnte man eine Singleton-Instanz der Applikation erstellen, anstatt dauernd Zeiger mitzuführen.

Ansonsten müßte jede Klasse einen Owner besitzen, der auf das übergeordnete Objekt zeigt.
Du kanst dann ja Helperfunktionen definieren, welche die Mehrfachrückwärtsverkettung erledigen.

Nun, im Augenblick würde eine einzelne Applikation reichen. Sogar ein einzelner Desktop. Aber natürlich wäre es einfacher, das universell zu belassen. Trotzdem ist das schon eine Überlegung wert.

Eine wichtige Fragen: Ist es die richtige Entscheidung, das project in die applikation zu legen? Da bin ich mir relativ sicher.

Wobei ich mir absolut nicht sicher bin, ist die Frage wie man den Zugriff (ohne Singleton) am besten ermöglicht: An jedes Kind-Objekt, das die Klasse benötigt ein Zeiger übergeben, der dann im Kindobjekt referenziert wird? Oder tatsächlich über Parent-Zeiger hoch-hangeln?
Das ist ein prinzipielles Problem, das ich habe wenn ein Kind-Objekt Zugriff auf Objekte benötigt, die der Parent hält. Aber besonders wenn man in der Hirarchie mehr als eine Ebene höher gehen müßte (also z.B. der Parent des Parent des Parent das Objekt hält, das vom Child benötigt wird) frage ich mich, ob es wirklich gut ist, Parent-Zeiger zu verwenden, oder statt dessen nicht doch lieber Referenzen über die Konstruktoren bis ans Child-Objekt weiter zu geben.

Dafür muss man hier natürlich aufpassen, wenn das Objekt gelöscht wird, das du in jedem Fenster aus dem Zeiger ne NULL-Nummer machst ...

Schau dir das Dokument view prinzip, oder das observer (beobachter) muster in den design patterns an ... das prinzip selber wird Dir klar sein, aber in den meisten abhandlungen steht noch bisserl mehr, paar tricks, wie man mehrere Ebenen verehiratet ... und auch dass die meisten "pattern" nie allein auftreten.
Was gleich weitere Fragen aufwirft ...
Wer sollte deine Fenster/Widgets/views "erzeugen"(klingt schon nach fast nach erzeugermuster)? Machts das fenster selber ? oder gibt es ne zentrale instanz (Objectfactory), wohin dein parentfenster sein Befehl (Befehlsmuster) zum erzeugen eines widgets / unterfensters schickt, natuerlich mit verweis auf sich selbst fuer die Fensterhirarchie. Wer genau weiss den, welches Project, welches fenster und was weiss ich noch fuern context grad "aktuell" sind ???

Wie gesagt, da haben sich schon ne menge anderer den kopf zerbrochen ... in Hirarchien in mehreren ebenen da toben sich die designer eh voll aus

Ciao ...

Mit dem parent bist du auf alle Fälle auf eine Struktur festgenagelt.
Wenn du z.B. sagst "ProjectWindow" kann mein Projekt anzeigen und du hangelst dich durch, ist diese Klasse darauf angewiesen, dass sie sich durchhangeln kann, ist also auf diesen Kontext festgenagelt. Wenn man ihr aber nen Zeiger füttert und sagt: "hier hast du ein Projekt, jetzt sieh zu das du es anzeigst", dann ist die nicht so sehr daran gebunden, wo das Objekt herkommt.

Hm. Ja. Das sehe ich ein. Ich habe das Gefühl, das ist die flexiblere Lösung. Allerdings bin ich mir sehr unsicher, was passiert, wenn meine Anwednung wachsen wird (und das wird sie definitiv!). Ich kann schwer abschätzen ob ich am Ende nicht gigantische Konstruktoren habe, die alle möglich zeiger oder Referenzen gefüttert bekommen.

Ich bin hin und her gerissen zwischen einem direkten Parent und dem übergeben einzelner Zeiger. Wie du sagst, ist das eine sehr einfach aber unflexibel und das andere aufwändig aber modularer. Hier wäre eine Regel schön, anhand derer man sich diese Entscheidung erleichtern kann.

Pellaeon schrieb:

Dafür muss man hier natürlich aufpassen, wenn das Objekt gelöscht wird, das du in jedem Fenster aus dem Zeiger ne NULL-Nummer machst ...

Wenn ich nicht Zeiger übergebe, sondern Referenzen auf Zeiger, dann erledigt sich das!?

Ich hab einzwischen auch über das Singleton Muster nachgedacht. Auch hier bin ich hin und her gerissen. Wenn ich dem Application-Object z.B. den Namen meiner Anwendung mitgebe, den ich an allen Ecken und Enden benötige, dann ist solch ein einzigartiges, global verfügbares Objekt natürlich schön. Wenn ich bisher auch noch keine richtig gute Singleton-Lösung für dynamische Singleton-Objekte (und vor allem deren Destruktion!) gesehen habe. Auch geht es mir gegen den Strich, eine Klasse zu schreiben, die am Ende (selbst wenn man es garnicht will) zur "Einzigartigkeit" verdonnert ist. Viel lieber wäre es mir, wenn ich die Application-Klasse ohne Veränderung sowohl Singleton als auch nicht-Singleton erzeugen könnte. Aber im Augenblick habe ich hierfür keine vernünftige Idee... naja, man könnte natürlich eine einfache, globale Funktion erzeugen, die einen statischen Zeiger zurück liefert, den man manuell initalisiert (bei der Erzeugung des Applikation Objekts) und wieder löscht (bei der Destruktion des Application Objekts). So primitiv das ist, so effektiv erscheint es mir in diesem speziellen Fall (so viele Application objekte erzeugt man ja nicht jeden Tag, das man das nicht per Hand erledigen könnte).