Ich schreibe eine Audio-Processing-Standalone-Anwendung. Ich habe ein AudioManager -Objekt, das Dinge mit der Engine zu tun hat (wie E / A-Geräteverwaltung, Routing der Signalverarbeitung, Laufstatus). Ich schreibe eine GUI um die AudioManager im Hintergrund zu steuern. Derzeit benötigt jede Komponente, die die Nachricht AudioManager melden muss, einen Zeiger darauf.
Das fängt an verrückt zu werden, wenn ein tief verschachteltes Objekt einen Zeiger auf AudioManager benötigt, da es bedeutet, dass ich den Zeiger durch die Konstruktoren von GUI-Objekten leiten muss, die nicht direkt AudioManager interessieren (nur) einige Unterkomponenten müssen dies wissen).
Ich könnte einfach AudioManager ein Singleton machen, um das Boilerplate zu vermeiden, aber der Informationsfluss von der Klasse ist bidirektional, also ist das wahrscheinlich eine schlechte Idee. Ich fühle mich auch ein wenig fischig, alles in eine große Klasse einzuwickeln, aber es macht es ein bisschen leichter, herumzugehen. Gibt es ein gemeinsames Muster, um zu vermeiden, dass der hirnlose Zeiger passiert?
Unten ist ein bisschen Pseudocode zu sehen, der einige Konstruktoren zeigt, die den grundlegenden Typ des Problems hervorheben. Ich habe dieses C ++ 11 markiert, um zu sehen, ob das irgendwelche einzigartigen Lösungen gibt.
%Vor%In Ihrem Beispiel sollte "SomeWidget" seine tatsächliche Abhängigkeit, "SomeThingy", nicht ein AudioManager sein.
Normalerweise bedeutet es, wenn die ganze Welt eine Klasse referenziert, dass die Klasse zu viel tut. Der Name "XyzManager" weist normalerweise auf ein Problem aus demselben Grund hin. (Klassen sollten nach dem benannt werden, was sie tun, und wenn der spezifischste Name verfügbar ist, der beschreibt, was er tut, ist "Verwalten", dann sollten es separate Klassen sein)
Dependenz-Injektion könnte helfen. Es hilft auch bei der Klärung von Eigentumsfragen und Sie erhalten eine bessere Testbarkeit kostenlos, da es einfach ist, Klassen auszuspionieren.
Die Idee ist, alle Ihre Ressourcenzuweisungen in die Fabrik zu verschieben; Ihre Klassen-Ctors nehmen nur (intelligente) Zeiger auf ihre unmittelbaren Abhängigkeiten.
Etwas in dieser Richtung:
%Vor%Nun wird sich die Komplexität in eurer Fabrikklasse zeigen, aber das Chaos wird sich nur auf einen Ort beschränken.
Wenn die Fabrik zu groß wird, können Sie sie in separate Klassen aufteilen; oder noch besser, haben verschiedene Fabriken für nicht verwandte Dinge : eine Fabrik, die Dinger herstellt, eine andere Fabrik für Widgets, etc.
Ich stimme Billy zu, ein Manager in der Nähe ist das Zeichen für eine Klasse, die versucht, zu viel zu machen, und das Design sollte überarbeitet werden. Wenn das God Object in einer Bibliothek von Drittanbietern lebt und Sie keine Kontrolle darüber haben ...: (
Tags und Links c++ user-interface c++11 design-patterns