多くのクラスで構成される信号処理経路があります。各処理クラスは、それぞれ独自のパラメーターを持つ小さなクラスの構成です。
今まで、私は怠け者で、すべての処理パラメータを別のパラメータ クラスに格納していました。これfriendをすべての処理クラスの 1 つにして、データ メンバーに直接アクセスできるようにしました。ただし、これにより、個々のブロックとパラメーター クラスの間の結合が非常に強くなり、設計の柔軟性が完全になくなります。
結合を減らすために機能するために必要な、それぞれの小さなプロセスが独自のプライベート データ メンバーを所有するように、コードを再設計しています。しかし、新しいパラメーターのセットが読み込まれると、個別の処理ブロックごとに (アクセサー関数を使用して) すべてのパラメーターを設定する複雑なメソッドが必要になります。このメソッド内のコマンドは、プロセスに強く結び付けられます。この結合を最小限に抑えるにはどうすればよいですか?
汎用コンテキスト（マップ内のキー/値を含む）または特定のコンテキストから継承する特定のコンテキストのいずれかを開発できます。これは、すべてのプロセスに共通のパラメーターを持ちます。
GenericContextの長所は、パラメーターを追加/削除するために変更する必要がないことですが、短所は、各パラメーターにアクセスするためのルックアップコストです。
SpecificContextの長所は、パラメーターにアクセスするためのルックアップコストがないことですが、短所は、パラメーターを追加/削除するための変更です。少なくともこのオプションでは、1つのプロセスに固有の具体的なContextクラスを変更するだけでよく、他のプロセスには影響を与えません。
Context Patternに似たものをお勧めします。プロセスの構築時に、1 つまたは複数のコンテキスト オブジェクトを使用してそれらをロードします (さまざまなプロセスに対してさまざまなコンテキストを使用できます)。次に、各プロセスが、指定されたコンテキスト オブジェクトから必要なパラメーターを要求して取得できるようにします。このようにして、プロセス パラメータを設定する責任を完全にそれらのプロセスに移します。つまり、プロセスは必要なパラメーターを認識しているため、プロセスは特定のコンテキスト オブジェクトからパラメーターを要求し、プライベートに格納されたメンバーを直接設定できます。
Context Pattern にはさまざまな種類がありますが、一般的にはかなり柔軟な概念です。