ホストで使用されるプラグインを構築しています。このプラグインは、どこからでも簡単にアクセスしたいサービスにシングルトンを使用しています。問題は、実行可能なものに固有の同じプラグイン、同じ（静的）シングルトンを数回インスタンス化すると、インスタンス化されたすべてのプラグインの中でシャードになります。一般的に言えば、シングルトン (c++) の範囲を縮小する方法はありますか? 各プラグインはそれ自体がインスタンスであるため、明らかにプラグインのルート クラスをそのすべてのサブクラスに渡すことができますが、可能な限り同じグローバル シングルトン デザインを維持したいと考えています。
2 に答える
3
シングルトンを持つ理由はありますか？論理的根拠は、1 つしかないことを強制する必要があり、単一のアクセス ポイントを提供する必要がある場合です。これらが実際の要件でない場合は、要件を作成して、必要な場所に渡します。
私は徐々にシングルトンを取り除きます。
シングルトンは多くのことをしますか、それともあまりしませんか?
部分に分割する必要があるかもしれません。
あまり機能しない場合は、必要な場所に渡して、シングルトン性を取り除きます。
多くのサービスを提供する場合は、サービスごとにインターフェイスを作成し、それらを必要な場所に渡します。設計が改善され、よりテストしやすくなり、理解しやすくなります。
最初は、インターフェイスの実装は元のシングルトンに委任できましたが、最終的には自己完結型にしたいと考えています。
于 2012-12-30T11:29:48.390 に答える
0
シングルトンは、静的変数を内部的に使用します。この静的変数のスコープは、現在の実行可能ファイルによって定義および分割されているソース ファイルによって指定されます。これらの理由により、同じホスト (および同じ実行可能ファイル) で実行している間、両方のプラグイン (同じコード) は同じ静的変数 (拡張により同じシングルトン) を共有します。この質問では、各プラグインのコードが同じであると想定しているため、これらのシングルトンを分割する唯一の方法は、新しい実行可能ファイルを実行することです。これは、たとえば、両方のプロセスが独自のメモリ範囲を保持する fork unix コマンドを使用して実行できます。明らかに（ほとんどの人がコメントしたように）、プロセスをフォークすることは無駄な複雑さを追加するだけなので、この場合はシングルトンの使用を避ける方がはるかに優れたアプローチです。
于 2013-01-08T14:10:36.693 に答える