2011-09-22 22 views
8

我试图描述应用程序,我正在根据需要进行更详细的构建,所以我提前为论文道歉!我的程序结构/设计所需的输入

我正在设计和构建一个相当大的音乐应用程序,使用C++ Juce框架,简而言之,它将接收OSC消息并将它们转换为音频和MIDI数据。该应用程序有三个“模式”,每个模式定义OSC消息将产生什么样的声音。用户可以应用模式和另一些模式设置来定义每个OSC消息“触发”的声音。

下面是程序的类关系和层次结构的基本框图概述,或者至少我理论上是如何想象的。为了澄清Juce术语,'Component'类基本上是一个GUI对象/类,它在屏幕上显示内容并允许用户进行交互。

Basic block diagram http://liamlacey.web44.net/images/Software_block_diagram.jpg

我是一个有经验的C程序员,但我是相当新的C++和面向对象的设计。我理解的最多,如果它很好,但我遇到的主要问题是在构建所有类以具有正确的关系和层次结构,以便它们都可以正确通信,以便应用程序执行所需操作。

这里的每一类功能的简要说明:

  • OscInput - 这个基类使用oscpack库监听OSC消息。如果在同一UDP端口上有多个侦听器,则只有一个类可以从此基类继承,因为应用程序将会崩溃。

  • Main - 应用程序启动。从OscInput继承,以便每次收到OSC消息时,在此类中调用回调函数

  • MainWindow - 应用程序主文档窗口 - 默认为Juce应用程序。

  • MainComponent - 应用程序的主要/后台组件/ GUI - 默认为Juce应用程序。

  • Mode1Component/Mode2Component/Mode3Component - 每个组件类的单个实例被调用并从MainComponent其用于由用户改变的每个OSC消息做什么的设置显示。

  • SubComponent1 - 调用此组件类的单个实例并从MainComponent中显示。

  • SubComponent2 - 调用此组件类的48个实例并从SubComponent1中显示。每个实例用于显示正在接收的不同OSC消息的值。

  • Mode1/Mode2/Mode3 - 每个这些类的单个实例从Main调用。根据Settings类中的值/变量,每个类用于实际将OSC消息转换为音频或MIDI数据。

  • Settings - 该类的一个实例,用于存储控制从每个不同的OSC消息产生的声音的设置。

我很高兴我有所有组件/ GUI类的布局和正确的方式连接。我也有传入的OSC消息正常工作。但它是Settings类实例的关系,我不太确定如何实现。下面是我需要帮助的关系:

  • 模式1,模式2和模式3的单一实例都需要从设置类实例检索值
  • MainComponent,Mode1Component,Mode2Component,Mode3Component的单一实例的所有需要将值发送到Settings类实例,以及从实例中检索值。
  • SubComponent2的所有48个实例需要检索OSC消息

因此,我有以下问题:

  • 应该在哪里Settings类的实例可以从让所有相关的类实例提到的所谓上面可以和它沟通吗?我只想要这个类的一个实例需要被许多其他类访问,所以它应该是一个全局,单例或静态类?我一直在研究似乎是我正在寻找的辛格尔顿设计模式,但是我得到的印象是,如果我可以考虑替代方法,我应该避免它。

  • 是否应该是Main类来监听OSC消息?我怎样才能让SubComponent2接收OSC消息以及Mode1,Mode2和Mode3类实例?

  • 应该从Main调用功能类(Mode1,Mode2和Mode3)吗?我试图将所有功能和GUI代码分开,因为当我处理应用程序的功能编程时,我有其他人正在处理GUI编程。

  • 任何人都可以发现我的程序设计模式中的任何主要缺陷?

任何帮助将不胜感激!

感谢

+5

我们需要一个LiamLacey.StackExchange.Com网站来回答这个巨兽。 –

+2

祝你好运,获得回应 - 可能会缩小问题的范围,让志愿者提供一些建议。 –

+0

是的,我为这个冗长的问题表示歉意 - 总是在撰写简短的简短描述的散文方面做得更好! –

回答

1

关于你的“主”的问题:你不应该和消息处理在同一类/组件的责任(“separation of concerns”)组合“应用程序启动”。你所描述喜欢发布/订阅模式

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

如果你想使你的架构真正面向消息,这里不是一切要看“主”和“主”做的一个应用程序的气味不依赖于一切,我建议你看看“流程设计”。看看这里

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

为单是确定的,当你需要这些设置几乎无处不在程序中实现一个设置类的实例。至少它比静态类更好测试。但是你应该避免把太多东西放在那里,因为很多事情可能取决于设置,这可能会对后来的可维护性产生负面影响。

+0

因此,除了Main之外的其他类应该是'OSC监听器'类呢?我是否应该使用Observer设计模式将OSC消息发送到程序中的正确位置? –

+0

@Liam:“Main”是OSC监听器,另一个类是启动,或者“Main”是启动,另一个是监听。 “观察者”是发布者/订阅者的子集,可能适用于此。这是你的决定,如果这是正确的工具,你知道最好的细节。 –