8

作成しているアプリケーションについて、必要に応じて詳細に説明するように心がけましたので、事前にお詫び申し上げます。

私は、C ++ Juceフレームワークを使用して、かなり大規模な音楽アプリケーションを設計および構築しているところです。このアプリケーションは、一言で言えば、OSCメッセージを取り込み、オーディオおよびMIDIデータに変換します。アプリケーションには3つの「モード」があり、それぞれがOSCメッセージによって生成されるサウンドの種類を定義します。ユーザーは、モードとさらに一連のモード設定を適用して、各OSCメッセージが「トリガーする」サウンドを定義できます。

以下は、プログラムのクラス関係と階層の基本的なブロック図の概要、または少なくとも私が理論的にどのように想像するかです。Juceの用語を明確にするために、「Component」クラスは基本的にGUIオブジェクト/クラスであり、画面に表示され、ユーザーとの対話を可能にします。

基本的なブロック図http://liamlacey.web44.net/images/Software_block_diagram.jpg

私は経験豊富なCプログラマーですが、C++とOOPの設計にはかなり慣れていません。私はそれがうまくいけばほとんど理解していますが、私が抱えている主な問題は、アプリケーションが必要なことを実行するためにすべてのクラスが適切に通信できるように、すべてのクラスが正しい関係と階層を持つように構造化することです。 。

各クラスの機能について簡単に説明します。

  • OscInput-この基本クラスは、oscpackライブラリを使用してOSCメッセージをリッスンします。同じUDPポートに複数のリスナーがある場合、アプリケーションがクラッシュするため、この基本クラスから継承できるクラスは1つだけです。

  • 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クラスインスタンスの関係です。これが私が助けを必要としている関係です:

  • Mode1、Mode2、およびMode3の単一インスタンスはすべて、Settingクラスインスタンスから値を取得する必要があります
  • MainComponent、Mode1Component、Mode2Component、Mode3Componentの単一インスタンスはすべて、設定クラスインスタンスに値を送信し、インスタンスから値を取得する必要があります。
  • SubComponent2の48個のインスタンスすべてがOSCメッセージを取得する必要があります

したがって、次の質問があります。

  • Settings上記の関連するすべてのクラスインスタンスがクラスインスタンスと通信できるようにするには、クラスインスタンスをどこから呼び出す必要がありますか?他の多くのクラスからアクセスする必要があるこのクラスの単一のインスタンスのみが必要なので、グローバル、シングルトン、または静的クラスにする必要がありますか?探しているシングルトンのデザインパターンを研究してきましたが、できれば避けて、別の方法を考えるべきだという印象を受けました。

  • MainOSCメッセージをリッスンするクラスである必要がありますか?SubComponent2にOSCメッセージとMode1、Mode2、およびMode3クラスインスタンスを受信させるにはどうすればよいですか?

  • 機能クラス(Mode1、Mode2、およびMode3)をMainから呼び出す必要がありますか?アプリケーションの機能プログラミングを扱っている間、他の誰かがGUIプログラミングを扱っているので、すべての機能とGUIコードを別々に保とうとしています。

  • 誰かが私のプログラムのデザインパターンの大きな欠陥を見つけることができますか?

どんな助けでも大歓迎です!

ありがとう

4

1 に答える 1

1

「メイン」に関する質問について:「アプリケーションの起動」と同じクラス/コンポーネントでのメッセージ処理の責任(「関心の分離」)を混在させないでください。あなたが説明していることは、パブリッシャー/サブスクライバーパターンのアプリケーションのようなにおいがします

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

プログラムのほぼすべての場所でこれらの設定が必要な場合は、設定クラスインスタンスをシングルトンとして実装しても問題ありません。少なくとも、静的クラスよりもテスト可能です。ただし、設定に依存するものが多く、後の保守性に悪影響を与える可能性があるため、あまり多くのものを入れないようにする必要があります。

于 2011-09-22T11:44:45.090 に答える