2011-09-22 5 views
8

私は必要に応じて詳細に構築しているアプリケーションについて説明しようとしていますので、事前に謝罪します!私のプログラムの構造/デザインに必要な入力

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

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

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

私は、しかし、私はC++とOOPの設計にかなり新たなんだ、経験豊富なCプログラマです。私が大部分を理解しているのは大丈夫ですが、私が気付いている大きな問題は、すべてのクラスが正しい関係と階層を持つように構造化することであり、アプリケーションが必要なことをするためには、 。 - この基底クラスは、OSCメッセージをリスンするoscpackライブラリを使用しています

  • OscInput:ここ

    は、各クラスが何をするかの簡単な説明です。同じUDPポート上に複数のリスナーが存在する場合、アプリケーションがクラッシュするため、この基本クラスから継承できるクラスは1つだけです。

  • Main - アプリケーションの起動。 OscInputから継承するので、OSCメッセージが受信されるたびに、このクラス内でコールバック関数が呼び出されます。

  • MainWindow - アプリケーションのメインドキュメントウィンドウ - デフォルトのJuceアプリケーションです。

  • MainComponent - アプリのメイン/バックグラウンドコンポーネント/ GUI - デフォルトのJuceアプリ。

  • Mode1Component/Mode2Component/Mode3Component - これらの成分クラスのそれぞれの単一のインスタンスが呼び出され、各OSCメッセージが何をするかの設定を変更するためにユーザによって使用されるMainComponentから表示されます。

  • SubComponent1 - このコンポーネントクラスの1つのインスタンスが呼び出され、MainComponentから表示されます。

  • SubComponent2 - このコンポーネントクラスのインスタンスが48個呼び出され、SubComponent1から表示されます。各インスタンスは、受信されている別のOSCメッセージの値を表示するために使用されます。

  • Mode1/Mode2/Mode3 - これらの各クラスの1つのインスタンスは、Mainから呼び出されます。各クラスは、Settingsクラス内の値/変数に基づいて、実際にOSCメッセージをオーディオデータまたはMIDIデータに変換するために使用されます。

  • Settings - このクラスの1つのインスタンス。異なるOSCメッセージから生成されるサウンドを制御する設定を格納するために使用されます。

すべてのコンポーネント/ GUIクラスがレイアウトされ、正しい方法で接続されていることはかなり幸せです。私はまた、受信OSCメッセージが正常に動作している。しかし、それは設定クラスのインスタンスの関係で、私はどのように実装するのかよく分かりません。ここで私は助けが必要な関係は以下のとおりです。

  • モード1、モード2、及びモード3の単一のインスタンスすべてが設定クラスインスタンスの値
  • MainComponent、Mode1Component、Mode2Component、Mode3Componentすべての単一のインスタンスを取得する必要がありますSettingsクラスのインスタンスに値を送信し、インスタンスから値を取得する必要があります。 SubComponent2の
  • すべての48個のインスタンスは、OSCメッセージを取得する必要が
  • したがって

I以下の質問があります:Settingsクラスのインスタンスは、関連するすべてのクラスインスタンスが言及したように呼ばれるべき

  • 上記と通信できますか?私は、他の多くのクラスからアクセスする必要があるこのクラスのインスタンスを1つだけ必要とします。グローバル、シングルトン、または静的クラスである必要がありますか?私が探していると思われるシングルトンのデザインパターンを勉強してきましたが、できるならば避けて、別の方法を検討しなければならないという印象を受けます。

  • OSCメッセージをリッスンするのはMainクラスである必要がありますか? OSCメッセージだけでなく、Mode1、Mode2、Mode3クラスのインスタンスを受信するにはどうすればSubComponent2を入手できますか?

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

  • 誰も私のプログラムのデザインパターンに大きな欠陥があるのを発見できますか?

ご協力いただければ幸いです。 「メイン」のご質問については

おかげ

+5

LiamLacey.StackExchange.Comのウェブサイトでこの巨大な動物たちに答える必要があります。 –

+2

幸運にも応答を得ることができます。誰かが何らかのアドバイスをボランティアして管理できるものに質問を絞り込んでください。 –

+0

はい、私は長い間巻き込まれた質問をお詫びします。 –

答えて

1

:あなたは、同じクラス/コンポーネント(「separation of concerns」)でのメッセージ処理のために責任を持って、「アプリケーションの起動」を混在させることはできません。あなたはない、すべてが「メイン」に依存しており、「メイン」はありませんパブリッシャー/サブスクライバパターン

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

そして、あなたはあなたのアーキテクチャが実際にメッセージ指向にしたい場合のアプリケーションのような臭いを記述しているものすべてに依存しているわけではありませんが、私はあなたに "Flow Design"を見てみることをお勧めします。ここにあなたがほとんどどこでもあなたのプログラムでこれらの設定を必要とするときシングルトンは、okですとして設定クラスのインスタンスを実装

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リスナー'クラスにする必要がありますか? OSCメッセージをプログラムの適切な場所に送信するためにオブザーバーデザインパターンを使用することを検討する必要がありますか? –

+0

@Liam: "Main"はOSCリスナーで、別のクラスはスタートアップを実行します。 "Main"はスタートアップ用で、もう1つはリスン用です。 「Observer」は出版社/サブスクライバのサブセットであり、ここでは適用可能です。これが適切なツールであるかどうかはあなたの判断です。詳細を最もよく知っています。 –

関連する問題