Memberzugriff bei nicht-vorhandener Klassendefinition?
-
Hi,
Vermutlich ist das trivial, aber ich will nur sicher gehen.
Ich habe zirkuläre Abhängigkeiten zwischen drei Klassen. Dementsprechend muss ich mit so einigen Vorwärtsdeklarationen arbeiten.
Jetzt möchte ich in Klasse A einen Typ von Klasse B benutzen, d.h. B::innerer_Typ. Natürlich funktioniert das nicht, weil ja nur die Vorwärtsdeklaration bekannt ist. Gibt es einen eleganteren Weg als innerer_Typ in eine Headerdatei auszulagern? Es handelt sich halt nur um ein kleines, unscheinbares enum, weswegen es mir etwas Leid tun, dafür extra eine Datei aufzumachen...
Viele Grüße und danke im Voraus,
Eisflamme
-
Beschreibe mal, warum Du das machst, und nicht, was Du machst. Zirkulare Abhängigkeiten weisen sehr häufig auf Designprobleme hin.
-
Hi,
also ich bastele gerade an 3D-Shadern rum. Kurz gesagt habe ich einen ShaderController, der einzelne ShaderProgram(s) aggregiert. Ein ShaderProgram besteht wiederum aus einzelnen ShaderProgramParameter(s).
So weit nix zirkulär. Jetzt benötigt aber ein ShaderProgram zur Initialisierung einen bestimmten Context, den ShaderController verwaltet (da 1:1). Statt den Kontext direkt zu übergeben, übergebe ich eine Instanz vom ShaderController, damit sich das ShaderProgram den Context selbst holen kann.
Na ja und da haben wir's eigentlich schon. Es ist unnötig, den this-Zeiger zu übergeben, ich könnte den Context selbst ebenfalls überreichen.
Hm... und das Problem mit dem enum löse ich damit eigentlich bereits auch.
Cool, danke für die Hilfe!
-
Keine Ursache!
-
Eisflamme schrieb:
Na ja und da haben wir's eigentlich schon. Es ist unnötig, den this-Zeiger zu übergeben, ich könnte den Context selbst ebenfalls überreichen.
Du könntest nicht nur, du solltest auch.
Gibt ja keinen Grund warum das ShaderProgram ne Dependency zum ShaderController haben sollte.
-
Sehr gut. Also sollte ich immer Abhängigkeiten vermeiden, solange es eben geht... ist das dir oberste Zielsetzung eines gut strukturierten Programms?
-
Eisflamme schrieb:
Sehr gut. Also sollte ich immer Abhängigkeiten vermeiden, solange es eben geht... ist das dir oberste Zielsetzung eines gut strukturierten Programms?
Jein. Es ist immer gut, wenn man wenig Abhängigkeiten hat. Denn dadurch kann man diesen Teil des Programms besser austauschen und muss weniger ändern. Überhaupt reduziert sich der Wartungsaufwand, da bei Änderungen weniger Tests gemacht werden müssen. Andererseits gibt es auch Programmteile, die sich ohnehin nie ändern bzw. die ohne Abhängigkeiten gar nicht auskommen.
Man muss also schauen, auf was es hinauslaufen soll und ob Änderungen dort zu erwarten sind, etc.
-
Eisflamme schrieb:
Sehr gut. Also sollte ich immer Abhängigkeiten vermeiden, solange es eben geht... ist das dir oberste Zielsetzung eines gut strukturierten Programms?
Ist das jetzt Zynismus/Irnoie oder Ernst?
Falls Ernst: man sollte unnötige Abhängigkeiten vermeiden, aber natürlich nicht um jeden Preis. Anders gesagt: sinnlose Abhängigkeiten.Aus einem Projekt gegriffen an dem ich gerade arbeite...
Beispielsweise ist es IMO OK, wenn eine ListBox Klasse ne Dependency zur ScrollBar Klasse hat, damit man unkompliziert eine ScrollBar "dranknoten" kann. (Vorausgesetzt die ListBox Klasse hat nicht sowieso schon ScrollBars integriert). Natürlich könnte man diese Abhängigkeit vermeiden, indem man eine zusätzliche Klasse dazwischenschaltet, die eben nur dafür sorgt ListBox und ScrollBar zu "koppeln" (koppeln jetzt im Sinn von dass das die ScrollBar die ListBox steuert, und die ListBox wiederum die Range der ScrollBar - NICHT im Sinn von Code-Dependency). Die Fragt ist, ob es den Aufwand wert ist. Nicht nur in der Library, sondern auch im User-Code, der dadurch auch aufwendiger wird.
Eine Sache die da schon sinnvoller wäre: die ListBox Klasse kennt nur ein IScrollBar Interface, und kann mit jedem Objekt zusammenarbeiten welches IScrollBar implementiert. Oder vielleicht sogar noch abstrakter, ala IValueInRangeControl - ein Interface für ein Control dem man eine Range einstellen kann, und das dem User ermöglicht einen Wert innerhalb dieser Range anzugeben/zu verändern.
Allerdings wieder die Frage ob der zusätzliche Aufwand Sinn macht, oder das Projekt dadurch nur unnötig komplex/schwer überschaubar wird.Kurz: man kann das Spiel beliebig weit treiben. Wo Schluss sein sollte muss man individuell entscheiden.
----
Umgekehrt sehe ich keinen Grund warum die ScrollBar Klasse die ListBox Klasse auch nur kennen sollte. Theoretisch würde es vielleicht ein-zwei Zeilen Code sparen, aber es geht auch wunderbar ohne.
----
Was dein konkretes Beispiel angeht: warum sollte das ShaderProgram den ShaderController kennen? Gibt es irgendwelche Vorteile? Und Nachteile gibt es IMO viele, "löälö" hat ja schon einiges aufgezählt.
-
Hi,
Ja, die Frage klang etwas sehr blöd, aber war durchaus ernst gemeint, danke.
Ich muss ehrlich gestehen, dass ich nicht besonders viel nachgedacht hab, als ich das schrieb, weil ich genug damit beschäftigt war zu verstehen, wie das CG Toolkit funktioniert, bin ganz neu im Shader programmieren.
Aber ich denke, die Abhängigkeiten kriege ich jetzt raus und mache den Code damit deutlich schöner. Danke!
