Input data required for my program structure / design

Question

I tried to describe the application that I am building in detail, as needed, so I apologize in advance for the essay!

I am developing and creating a fairly large music application using the C ++ Juce framework, which in a nutshell receives OSC messages and turns them into audio and MIDI data. The application has three “modes”, each of which determines which sound will be generated by OSC messages. The user can apply the mode and advanced mode settings to determine the sound that each OSC message “triggers”.

The following is an overview of the basic flowcharts of class relationships and program hierarchies, or at least how I theoretically imagine it. To clarify Juce's terminology, the “Component” class is basically a GUI object / class that displays everything on the screen and allows the user to interact.

The main flowchart http://liamlacey.web44.net/images/Software_block_diagram.jpg

I am an experienced C programmer, however I am fairly new to C ++ and OOP design. I understand most of all if this is good, but the main problem I am facing is to structure all the classes so that they have the right relationships and hierarchy so that they can communicate normally so that the application does what it needs to do .

Here is a brief description of what each class does:

• OscInput - This base class uses the oscpack library to listen on OSC messages. Only 1 class can inherit this base class, because the application will crash if there are multiple listeners on the same UDP port.

• Main - launch the application. Inherits from OscInput so that every time an OSC message is received, a callback function is called in this class

• MainWindow - window of the main application document - by default for Juce applications.

• MainComponent - main / background component / application GUI - by default for Juce applications.

• Mode1Component / Mode2Component / Mode3Component - One instance of each of these component classes is called from MainComponent, which is used by the user to change the settings of what each OSC message does.

• SubComponent1 - from the MainComponent, one instance of this component class is called and displayed.

• SubComponent2 - from SubComponent1, 48 instances of this component class are called and displayed. Each instance is used to display the value of the other received OSC message.

• Mode1/Mode2/Mode3 - one instance of each of these classes is called from Main. Each class is used to actually convert OSC messages to audio or MIDI data based on the values ​​/ variables in the settings class.

• Settings is the only instance of this class that is used to store settings that control what sound is generated from each individual OSC message.

I am pretty happy that I have all the component / GUI classes that are laid out and connected correctly. I also have incoming OSC messages that work fine. But it is the attitude of the settings class instance that I’m not quite sure how to implement. Here are the relationships I need help with:

• The only instances of Mode1, Mode2, and Mode3 all need to get values ​​from an instance of the installation class
• The only instances of MainComponent, Mode1Component, Mode2Component, Mode3Component need to send values ​​to an instance of the settings class, as well as get values ​​from the instance.
• All 48 instances of SubComponent2 should receive OSC messages

Therefore, I have the following questions:

• Where should the instance of the Settings class be called so that all relevant instances of the class mentioned above can communicate with it? I need only one instance of this class that many other classes need to access, and should it be a global, Singleton, or static class? I am studying the Singleton design pattern, which I seem to be looking for, but I get the impression that I should avoid it, if possible, and consider alternative methods.

• Should the Main class listen for OSC messages? How can I get SubComponent2 to receive OSC messages, as well as instances of the Mode1, Mode2, and Mode3 class?

• Should function classes (Mode1, Mode2, and Mode3) be called from Main? I try to keep all the functionality and GUI separate, as I have someone else who is involved in GUI programming, while I deal with programming the functionality of the application.

• Can I identify any serious flaws in the design pattern of my program?

Any help would be greatly appreciated!

thanks

Answer 1

Regarding your questions about the “Main”: you should not confuse the “application launch” with the responsibility for processing messages in the same class / component (“ separation of problems ). What you describe smells like a publisher / subscriber template application.

http://en.wikipedia.org/wiki/Publish/subscribe

And if you want to make your architecture truly message-oriented, where not everything depends on “Main”, and “Main” does not depend on everything, I suggest you take a look at “Flow Design”. Look at here

http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx

http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx

Implementing an instance of the settings class as a singleton is okay when you need these settings almost everywhere in your program. At least it's better to check than a static class. But you should not put too many things, because a lot can depend on settings, which subsequently can adversely affect the maintenance of health.