私はシングルトンの嫌がらせではありませんが、虐待を受けていると私は知っています。シングルトンの使用を避けるための助けが必要
私はクロスプラットフォーム(Windows XP/Vista/7、Windows Mobile 6.x、Windows CE5、Windows CE6)になるアプリケーションを開発しています。このプロセスの一環として、私は、コードの重複を減らすために、コードを別々のプロジェクトに再組み込みしているため、インタルシステムの間違いを修正する機会があります。
別々に作られているアプリケーションのそのような部分は、非常にシンプルで、そのプロファイルマネージャです。このプロジェクトは、プロファイルの保存を担当します。これは、アプリケーションのすべての部分で使用されるいくつかの構成データを含むProfile
クラスを持っています。それはProfiles
を含むProfileManager
クラスを持っています。 ProfileManager
は、Profiles
をハードドライブ上の別個のXMLファイルとして読み書きし、アプリケーションが "アクティブ" Profile
を取得して設定できるようにします。シンプル。
最初の内部ビルドでは、GUIはアンチパターンSmartGUIでした。 MVC/MVPを使用しないWinForms実装でした。なぜなら、うまく設計されているのではなく、早く作業したいからです。これはシングルトンであるProfileManager
につながります。これはアプリケーションのどこからでもそうだったので、GUIはアクティブなProfile
にアクセスできました。
これは、私がちょうどProfileManager.Instance.ActiveProfile
に行って、必要に応じてシステムのさまざまな部分の設定を取得できることを意味しました。各GUIはプロファイルを変更することもできるので、各GUIには保存ボタンがあるため、すべてがProfileManager.Instance.SaveActiveProfile()
メソッドにもアクセスできました。
ここでシングルトンを使うのは間違いないと思うし、シングルトンが理想的ではないことも分かっているからだ。 これをより適切に処理する方法はありますか? ProfileManagerのインスタンスをすべてのコントローラ/プレゼンタに渡す必要がありますか? ProfileManagerが作成されると、他のコアコンポーネントが作成され、プロファイルが変更されたときにイベントに登録する必要があります。この例は非常にシンプルで、おそらく多くのシステムで共通の機能なので、シングルトンを回避する方法を学ぶには最適な場所だと思っています。
p.s.私は使用できる通常の.Net Frameworkクラスの多くを制限するCompact Framework 3.5に対してアプリケーションを構築する必要があります。
私は自分の古い習慣で立ち往生しているかもしれませんが、シングルトンを使うべき良い例としてこれを見ています。 –
これは実際にシングルトンインスタンスの理想的なケースのように聞こえます。 – msarchet
すべての答えをありがとう、これはシングルトンを使用するための適切な場所と思われる。 Factory/Dependency Injectionについてのフィードバックは考慮されますが、このアプリケーションはバックグラウンドで実行されるため、シンプルさとパフォーマンスの両方でシングルトンとして残しておきます。 – JonWillis