Входные данные необходимы для структуры / дизайна моей программы [ closed]

Трудно сказать, о чем здесь спрашивают. Этот вопрос неоднозначный, расплывчатый, неполный, чрезмерно широкий или риторический, и на него нельзя разумно ответить в его нынешней форме. Чтобы прояснить этот вопрос и снова открыть его, посетите справочный центр .

Закрыт 8 лет назад .

Я попытался подробно описать приложение, которое я создаю, по мере необходимости, поэтому заранее прошу прощения за эссе!

Я занимаюсь проектированием и созданием довольно большого музыкального приложения с использованием фреймворка C ++ Juce, которое в двух словах принимает сообщения OSC и превращает их в аудио- и MIDI-данные. В приложении есть три «режима», каждый из которых определяет, какой звук будет воспроизводиться сообщениями OSC. Пользователь может применить режим и дополнительные параметры режима, чтобы определить звук, который «запускает» каждое сообщение OSC.

Ниже приводится обзор базовой блок-схемы отношений классов и иерархии программ, или, по крайней мере, как я теоретически это себе представляю. Чтобы прояснить терминологию Juce, класс «Компонент» - это в основном объект / класс графического интерфейса пользователя, который отображает вещи на экране и позволяет взаимодействовать с пользователем.

Базовая блок-схема http://liamlacey.web44.net/images/Software_block_diagram.jpg

Я опытный программист на C, но довольно новичок в дизайне C ++ и ООП. Я понимаю больше всего, если все в порядке, но основная проблема, с которой я сталкиваюсь, заключается в структурировании всех классов, чтобы иметь правильные отношения и иерархию, чтобы все они могли правильно взаимодействовать, чтобы приложение могло делать то, что ему нужно .

Вот краткое описание того, что делает каждый класс:

OscInput - этот базовый класс использует библиотеку oscpack для прослушивания сообщений OSC. Только 1 класс может наследовать от этого базового класса, так как приложение выйдет из строя, если на одном и том же UDP-порте будет несколько слушателей.
Main - запуск приложения. Наследуется от OscInput, поэтому каждый раз при получении сообщения OSC в этом классе вызывается функция обратного вызова
MainWindow - главное окно документа приложения - по умолчанию используются приложения Juce.
MainComponent - основной / фоновый компонент / графический интерфейс приложения - по умолчанию для приложений Juce.
Mode1Component / Mode2Component / Mode3Component - отдельный экземпляр каждого из этих классов компонентов вызывается и отображается из MainComponent, которые используются пользователем для изменения настроек что делает каждое сообщение OSC.
SubComponent1 - единственный экземпляр этого класса компонента вызывается и отображается из MainComponent.
SubComponent2 - 48 экземпляров этого класса компонентов вызываются и отображаются из SubComponent1. Каждый экземпляр используется для отображения значения отдельного принимаемого сообщения OSC.
Mode1 / Mode2 / Mode3 - один экземпляр каждого из этих классов вызывается из Main. Каждый класс используется для фактического преобразования сообщений OSC в аудио- или MIDI-данные на основе значений / переменных в классе Settings.
Настройки - единственный экземпляр этого класса, который используется для хранения настроек, управляющих тем, какой звук воспроизводится из каждого отдельного сообщения OSC.

Я очень рад, что у меня все классы компонентов / GUI выложены и подключены правильно. У меня также есть входящие сообщения OSC, работающие нормально. Но я не совсем уверен, как реализовать это отношение экземпляра класса Settings. Вот отношения, с которыми мне нужна помощь:

Отдельные экземпляры Mode1, Mode2 и Mode3 все должны получать значения из экземпляра класса Setting
Отдельные экземпляры MainComponent, Mode1Component, Mode2Component, Mode3Component все должны отправить values в экземпляр класса Settings, а также извлекать значения из экземпляра.
Все 48 экземпляров SubComponent2 должны получать сообщения OSC

Поэтому у меня есть следующие вопросы:

Откуда должен быть вызван экземпляр класса Settings , чтобы все соответствующие экземпляры класса, упомянутые выше может с ним общаться? Мне нужен только один экземпляр этого класса, который должен быть доступен для многих других классов, поэтому должен ли он быть глобальным, синглтоновым или статическим классом? Я изучал шаблон проектирования Singleton, который мне кажется именно тем, что я ищу, но у меня сложилось впечатление, что мне следует избегать его, если можно, и рассмотреть альтернативные методы.
Должен ли быть класс Main , который прослушивает сообщения OSC? Как я могу заставить SubComponent2 получать сообщения OSC, а также экземпляры классов Mode1, Mode2 и Mode3?
Должны ли классы функциональности (Mode1, Mode2 и Mode3) вызываться из Main? Я пытаюсь сохранить всю функциональность и код графического интерфейса отдельно, так как у меня есть кто-то другой, занимающийся программированием графического интерфейса, а я занимаюсь программированием функциональности приложения.
Может ли кто-нибудь заметить какие-либо серьезные недостатки в шаблоне проектирования моей программы?

Любая помощь будет принята с благодарностью!

Спасибо

задан marc_s 23 January 2016 в 09:48

0 ответов

Другие вопросы по тегам:

c++ design-patterns structure osc

Входные данные необходимы для структуры / дизайна моей программы [ closed]

0 ответов

Похожие вопросы: