Ich habe versucht, die Anwendung zu beschreiben, die ich bei Bedarf sehr detailliert erstelle, also entschuldige ich mich im Voraus für den Aufsatz!
Ich bin gerade dabei, eine ziemlich große Musik-Anwendung zu entwerfen und zu erstellen, die das C ++ Juce-Framework verwendet, das OSC-Nachrichten kurz und bündig in Audio- und MIDI-Daten umwandelt. Die Anwendung verfügt über drei "Modi", die jeweils definieren, welche Art von Sound von den OSC-Nachrichten erzeugt wird. Der Benutzer kann einen Modus und eine weitere Reihe von Moduseinstellungen anwenden, um den Ton zu definieren, den jede OSC-Nachricht "auslöst".
Im Folgenden finden Sie eine grundlegende Übersicht über die Klassenbeziehung und Hierarchie der Programme, oder zumindest, wie ich sie mir theoretisch vorstelle. Um die Juce-Terminologie zu verdeutlichen, ist eine "Komponenten" -Klasse im Grunde genommen ein GUI-Objekt / eine Klasse, die Dinge auf dem Bildschirm anzeigt und Benutzerinteraktion erlaubt.
Basis-Blockdiagramm http://liamenty.web44.net/images/Software_block_diagram.jpg
Ich bin ein erfahrener C-Programmierer, aber ich bin ziemlich neu in C ++ und OOP-Design. Ich verstehe am meisten, wenn es in Ordnung ist, aber das Hauptproblem, das ich habe, ist in Bezug auf die Strukturierung aller Klassen die richtigen Beziehungen und Hierarchie zu haben, so dass sie alle richtig kommunizieren können, damit die Anwendung tun kann, was sie tun muss .
Hier ist eine kurze Beschreibung der einzelnen Klassen:
OscInput - Diese Basisklasse verwendet die Oscpack-Bibliothek, um auf OSC-Nachrichten zu warten. Nur 1 Klasse kann von dieser Basisklasse erben, da die Anwendung abstürzt, wenn mehrere Listener am selben UDP-Port vorhanden sind.
Main - Anwendungsstart. Erbt von OscInput, so dass jedes Mal, wenn eine OSC-Nachricht empfangen wird, eine Callback-Funktion innerhalb dieser Klasse aufgerufen wird
MainWindow - Das Hauptdokumentfenster der Apps - Standard ist Juce apps.
MainComponent - die Haupt- / Hintergrundkomponente / GUI der App - standardmäßig Juce-Apps.
Mode1Component / Mode2Component / Mode3Component - eine einzelne Instanz jeder dieser Komponentenklassen wird von MainComponent aufgerufen und angezeigt, die vom Benutzer verwendet werden, um die Einstellungen der einzelnen OSC-Nachrichten zu ändern.
SubComponent1 - Eine einzelne Instanz dieser Komponentenklasse wird von MainComponent aufgerufen und angezeigt.
SubComponent2 - 48 Instanzen dieser Komponentenklasse werden von SubComponent1 aufgerufen und angezeigt. Jede Instanz wird verwendet, um den Wert einer anderen empfangenen OSC-Nachricht anzuzeigen.
Mode1/Mode2/Mode3 - eine einzelne Instanz jeder dieser Klassen wird von Main aufgerufen. Jede Klasse wird verwendet, um die OSC-Nachrichten basierend auf Werten / Variablen innerhalb der Settings-Klasse in Audio- oder MIDI-Daten umzuwandeln.
Settings - Eine einzelne Instanz dieser Klasse, die zum Speichern von Einstellungen verwendet wird, die steuern, welcher Sound von jeder einzelnen OSC-Nachricht erzeugt wird.
Ich bin ziemlich glücklich, dass ich alle Komponenten / GUI-Klassen richtig ausgelegt und verbunden habe. Ich habe auch eingehende OSC-Nachrichten funktionieren gut. Aber es ist die Beziehung der Settings-Klasseninstanz, bei der ich mir nicht ganz sicher bin, wie ich sie implementieren soll. Hier sind die Beziehungen, mit denen ich Hilfe brauche:
Deshalb habe ich folgende Fragen:
Wo soll die Klasseninstanz Settings aufgerufen werden, damit alle oben genannten relevanten Klasseninstanzen mit ihr kommunizieren können? Ich möchte nur eine einzelne Instanz dieser Klasse, auf die viele andere Klassen zugreifen müssen, also sollte es eine globale, Singleton oder statische Klasse sein? Ich habe das Singleton-Entwurfsmuster studiert, das genau das zu sein scheint, wonach ich suche, aber ich habe den Eindruck, dass ich es vermeiden sollte, wenn ich kann und alternative Methoden in Erwägung ziehe.
Soll die Main -Klasse auf OSC-Nachrichten warten? Wie kann ich SubComponent2 dazu bringen, OSC-Nachrichten sowie die Klasseninstanzen Mode1, Mode2 und Mode3 zu empfangen?
Sollen die Funktionalitätsklassen (Mode1, Mode2 und Mode3) von Main aufgerufen werden? Ich versuche, alle Funktionalität und GUI-Code getrennt zu halten, da ich jemand anderen mit GUI-Programmierung beschäftigen, während ich mit der Funktionalität Programmierung der Anwendung beschäftigt bin.
Kann jemand größere Fehler im Designmuster meines Programms entdecken?
Jede Hilfe würde sehr geschätzt werden!
Danke
Bei Ihren Fragen zu "Main": Sie sollten "Application Startup" nicht mit der Verantwortung für die Nachrichtenverarbeitung in der gleichen Klasse / Komponente (" Trennung der Bedenken "). Was du beschreibst riecht wie eine Anwendung des Publisher / Subscriber-Patterns
Und wenn Sie Ihre Architektur wirklich nachrichtenorientiert gestalten wollen, wo nicht alles von "Main" abhängt, und "Main" nicht von allem abhängt, schlage ich Ihnen vor, sich "Flow Design" anzusehen. Schau hier
Das Implementieren einer Einstellungsklasseninstanz als Singleton ist in Ordnung, wenn Sie diese Einstellungen fast überall in Ihrem Programm benötigen. Zumindest ist es besser testbar als eine statische Klasse. Sie sollten jedoch vermeiden, zu viele Dinge hineinzulegen, da viele Dinge von den Einstellungen abhängen können, die sich später negativ auf die Wartbarkeit auswirken können.
Tags und Links c++ design-patterns design structure osc
