一部のプログラム (つまり、サウンド合成、プロシージャル テクスチャ生成など) では、ユーザーは、グラフィカル エディターを使用して、プログラムのさまざまな機能を任意の方法で完全に自由に配置できます。ユーザーは、1 つまたは複数の「ノード」 (それぞれが 1 つまたは複数の入力から 1 つまたは複数の出力を生成する何らかの関数を表す) を配置し、最終的な出力を生成するために任意の方法でパッチ/接続することができます。
このようなソフトウェアの最適な表現は、ジェネレーター システム自体とそのグラフィック表現の両方に必要なデータ構造の観点から、どのようなものになるのだろうかと思います。ノードの入力と出力がさまざまなデータ型である可能性があり、ノードの種類によってはそれらの一部のみが有効である可能性があるという事実をモデル化する方法について、私は特に困惑しています。
では、モデル化する方法は次のとおりです。
私はこのようないくつかのシステムに関与してきました。物事を行うにはさまざまな方法があります。しかし、私が過去に行った一般的な方法の 1 つは、Node オブジェクトを他の Node オブジェクトにリンクさせることです。ノードには、何らかの IAction インターフェイスを介してアクション オブジェクトが含まれています。ユーザーは、特定のノードで IAction インターフェイスを実装する具体的なアクション オブジェクトを何らかの形で指定します (これには、通常、適用するフィルターのパラメーターなど、オブジェクトの状態を指定することも含まれます)。
次に、グラフを初期化 (コンパイル) および実行 (実行) し、入力の準備が整ったときにノードへの入力で IAction インターフェイスを呼び出すように調整し、出力を下流のノードに渡すフレームワークがあります。これは非常に単純なアルゴリズムです。すべての入力が存在するすべてのノードを並行して実行し (入力のないノードから開始)、入力が存在するまで残りを待機キューに入れます。
これは、その方法のほんの一例です。多くのバリエーションがあり、指摘したようにこの手法を使用するシステムがたくさんあります。いくつかのフレームワークもあります (私が正しく理解していれば、 TPL Dataflowはその 1 つです)。
接続がノード間で一貫していることを確認する方法についてのあなたの質問に関して、これは私の意見では、フレームワークの機能とノードの機能のどちらかを選択することになります。極端な場合、フレームワークはグラフの「コンパイル時」に接続タイプを厳密に一致させることができます。もう 1 つのフレームワークでは、「実行時」にチェックするためにノードに任せることができます。後者は、ほとんどの接続がまったく同じタイプである場合 (たとえば、それらがすべてバイト ストリームである場合など) に適している可能性があります。
ところで、インターフェイス、リフレクション、オンザフライでのオブジェクトのロードなどのサポートが多いため、C++よりもJavaまたはC＃（または別のHLL）の方がおそらく簡単です（たとえば、C＃では、オブジェクトのタイプを簡単に指定してストリームから動的に作成しますが、C++ では自分でロールする必要があります)。
オブザーバー パターン、特にこの種の信号/スロット システムを確認することをお勧めします。 オブザーバー パターン、Boost.Signals
C++ を使用してしばらく前に取り組んだプロジェクトでは、シグナル/スロットを使用して、ユーザーが実行時にさまざまなオーディオ合成モジュールを動的に接続できるようにしていました。ただし、パフォーマンスに関してはトレードオフが発生する可能性があります。
さまざまな可能な入力のモデル化に関しては、信号オブジェクトに実際のデータを void ポインターとして含め、受信クラスが処理中に正しいと想定するデータ型を指定する文字列または列挙型を作成できます。ユーザーが最初にこれらのオブジェクトに接続すると、一種のコントラクトが返され (「これらはこのオブジェクトが送信する型です」)、処理が開始される前に実際の検証が行われる可能性があります。