タグ付けされた質問 「singleton」

シングルトンパターンは常にアンチパターンであると考える人もいます。どう思いますか？

65 design-patterns  singleton 

私の同僚は、「ロギング/キャッシングなどが横断的な関心事である」と言ってから、対応するシングルトンをどこでも使用して進めます。それでも、彼らはIoCとDIが大好きです。 SOLI Dの原則を破ることは本当に正当な言い訳ですか？

43 dependency-injection  solid  anti-patterns  singleton 

シングルトンパターンに関するさまざまな意見を読みました。一部の人は、すべてのコストで回避する必要があると主張し、他の人は、特定の状況で役立つ可能性があると主張しています。 シングルトンを使用する1つの状況は、特定のクラスAのオブジェクトを作成するためにファクトリー（たとえば、タイプFのオブジェクトf）が必要な場合です。ファクトリーは、いくつかの構成パラメーターを使用して一度作成され、その後、タイプAがインスタンス化されます。したがって、Aをインスタンス化するコードのすべての部分は、シングルトンfをフェッチし、新しいインスタンスを作成します。たとえば、 F& f = F::instance(); boost::shared_ptr<A> a = f.createA(); 一般的な私のシナリオは 最適化の理由（複数のファクトリオブジェクトは必要ありません）または共通の状態を共有するためにクラスのインスタンスが1つだけ必要です（たとえば、ファクトリはAのインスタンスをいくつ作成できるかを知っています） コードのさまざまな場所でFのこのインスタンスfにアクセスする方法が必要です。 このパターンが良いか悪いかについての議論には興味がありませんが、シングルトンの使用を避けたい場合、他にどのようなパターンを使用できますか？ 私が持っていたアイデアは、（1）レジストリからファクトリオブジェクトを取得するか、（2）プログラムの起動中のある時点でファクトリを作成し、パラメータとしてファクトリを渡すことでした。 ソリューション（1）では、レジストリ自体がシングルトンであるため、シングルトンを使用しないという問題を工場からレジストリに移行しました。 （2）の場合、ファクトリオブジェクトの元となる初期ソース（オブジェクト）が必要なので、別のシングルトン（ファクトリインスタンスを提供するオブジェクト）に再びフォールバックするのではないかと心配しています。このシングルトンのチェーンをたどると、他のすべてのシングルトン を直接または間接的に管理する1つのシングルトン（アプリケーション全体）に問題を減らすことができます。 この最後のオプション（他のすべての一意のオブジェクトを作成し、他のすべてのシングルトンを適切な場所に注入する1つの初期シングルトンを使用）は、許容できる解決策でしょうか？これは、シングルトンを使用しないことを勧めるときに暗黙的に提案される解決策ですか、それとも他の解決策は何ですか？ 編集 私の質問の要点は一部の人によって誤解されていると思うので、ここにいくつかの情報があります。ここで説明するように、シングルトンという言葉 は、（a）単一インスタンスオブジェクトを持つクラスと、（b）そのようなオブジェクトの作成とアクセスに使用されるデザインパターンを示すことができます。 物事を明確にするために、（a）には ユニークオブジェクト、（b）にはシングルトンパターンという用語を使用します。だから、私はシングルトンパターンと依存性注入が何であるかを知っています（最近、私は作業中のコードからシングルトンパターンのインスタンスを削除するためにDIを多用しています）。 私のポイントは、オブジェクトグラフ全体がmainメソッドのスタックにある単一のオブジェクトからインスタンス化されない限り、シングルトンパターンを通じていくつかの一意のオブジェクトに常にアクセスする必要があるということです。 私の質問は、完全なオブジェクトグラフの作成と配線をメインメソッドに依存させること（たとえば、パターン自体を使用しない強力なDIフレームワークを使用すること）が、シングルトンパターンを使用しない唯一のソリューションかどうか です。

27 design-patterns  programming-practices  anti-patterns  singleton 

私のコードのいくつかでは、次のような静的ファクトリーがあります。 public class SomeFactory { // Static class private SomeFactory() {...} public static Foo createFoo() {...} public static Foo createFooerFoo() {...} } コードのレビュー中に、これはシングルトンであることが提案され、注入されました。したがって、次のようになります。 public class SomeFactory { public SomeFactory() {} public Foo createFoo() {...} public Foo createFooerFoo() {...} } 強調すべきいくつかのこと： 両方の工場はステートレスです。 メソッド間の唯一の違いは、スコープ（インスタンスと静的）です。実装は同じです。 Fooは、インターフェースを持たないBeanです。 静的にするための引数は次のとおりです。 クラスはステートレスであるため、インスタンス化する必要はありません ファクトリをインスタンス化するよりも静的メソッドを呼び出す方が自然なようです シングルトンとしてのファクトリの引数は次のとおりです。 すべてを注入するのが良い 工場の無国籍にもかかわらず、注入によりテストが簡単になります（簡単にモックできます） 消費者をテストするとき、それはock笑されるべきです …

24 java  design-patterns  singleton  factory-method 

私は同僚のためにシングルトンを介した依存性注入の使用について聞いてきました。互いに置き換えることができる2つの直交パターンであるかどうかはまだわかりませんか？または、DIはシングルトンパターンをテスト可能にする方法ですか？ 次のコードスニペットをご覧ください。 IMathFace obj = Singleton.Instance; SingletonConsumer singConsumer = new SingletonConsumer(obj); singConsumer.ConsumerAdd(10,20); SingletonConsumer型のパラメータを受け入れていますIMathFace。内部的にシングルトンクラスにアクセスする代わりにSingletonConsumer、呼び出し元から渡されたシングルトンインスタンスを取得します。これは、依存性注入を介してシングルトンクラスを使用する良い例ですか？

17 c#  architecture  singleton 

従来、シングルトンは通常次のように実装されます public class Foo1 { private static final Foo1 INSTANCE = new Foo1(); public static Foo1 getInstance(){ return INSTANCE; } private Foo1(){} public void doo(){ ... } } Javaの列挙型を使用して、シングルトンを次のように実装できます。 public enum Foo2 { INSTANCE; public void doo(){ ... } } 2番目のバージョンと同じくらいすごいのですが、欠点はありますか？ （私はそれにいくつかの考えを与え、私は自分の質問に答えます;うまくいけば、より良い答えがあります）

14 java  singleton  enum 

RESTful APIを開発しており、リソースにDAOを使用すると便利だと思います。メモリを使用してそれらを格納するだけですが、使用することに決めた場合はライブラリを使用しているユーザーのドアを閉めたくないためです。 DAOのデータベース実装。 私の質問は、DAOがシングルトンであるかどうかです。そうでない場合、サービスにはDAOのインスタンスがあり、おおよそ次のようになります。 @Path("eventscheduler") public class EventSchedulerService { private IEventSchedulerDao dao = new EventSchedulerDao(); // in case a different implementation is to be used public void setEventSchedulerDao(IEventSchedulerDao dao) { this.dao = dao; } @Path("{uniqueName}") @GET @Produces(MediaType.APPLICATION_JSON) public Tournament getTournament(@PathParam("name") String uniqueName) { return dao.get(uniqueName); } @Path("create") @POST @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) …

14 java  design  design-patterns  singleton  dao 

私はC ++でOOPを勉強しており、これら3つの概念の定義を知っていても、それをいつどのように使用するかを本当に理解できません。 このクラスを例に使用してみましょう。 class Person{ private: string name; int age; public: Person(string p1, int p2){this->name=p1; this->age=p2;} ~Person(){} void set_name (string parameter){this->name=parameter;} void set_age (int parameter){this->age=parameter;} string get_name (){return this->name;} int get_age (){return this->age;} }; 1. シングルトン クラスが1つのオブジェクトのみを機能させるという制限はどのように機能しますか？ CANあなたは持っているだろう、クラス設計ONLY 2のインスタンスを？それとも3？ WHEN /必要な推奨シングルトンを使用していますか？それは良い習慣ですか？ 2. 抽象クラス 私の知る限り、純粋な仮想関数が1つしかない場合、クラスは抽象になります。だから、追加 virtual void print ()=0; しますよね？ なぜあなたは、そのオブジェクト必要とされていないクラスが必要でしょうか？ …

13 c++  object-oriented  singleton  class  abstract-class 

現在、私はインターンシップに4か月あります。コードをレビューするとき、上司は特定のオブジェクトを1つのアセンブリ内のいくつかの別個のクラスの多くのメソッドに対してローカルに保持していたことを嫌いました。彼は、私が毎回新しいオブジェクトを作成することを嫌い、代わりにどこからでもアクセスできる単一のオブジェクトを作成するように言った。したがって、静的クラス内で静的オブジェクトとして作成し、ここから参照するだけで使用する必要がありました。 私はプロとして4か月しかプログラミングしていないので、これにどう対処しますか？

13 teamwork  coding-standards  singleton 

Cocoa NSNotificationCenterなど、これらのメッセージハブスタイルのAPIに出くわすことがあります。http：//developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter_Class/Reference/Reference.html 通常、これらのAPIは、メッセージ/イベントをサブスクライブまたはブロードキャストするグローバルアクセスポイントを提供します。これは、依存関係がAPIで明示されていないがソースコードに隠されているフラットで非構造化のプログラムアーキテクチャを促進するため、これが問題だと考えています。オブジェクトの所有権と階層について考える必要はありませんが、プログラム内の任意のオブジェクトを呼び出すことで、任意のコードを呼び出すことができます。しかし、これは良いことでしょうか？ このパターンは一般に、プログラム設計の良し悪しを助長しますか？コードをテストするのが難しくなりますか、それとも簡単になりますか？ この質問が曖昧すぎるか広すぎる場合はご容赦ください。私は、このようなAPIの広範な使用の潜在的な結果と、それを使用できるさまざまな方法について頭をかき回しています。 編集：このパターンの最大の問題は、APIが依存関係とオブジェクトカップリングについて「嘘をつく」ことであり、この例で説明できることです。 myObj = new Foo(); myOtherObj = new Bar(); print myOtherObj.someValue; // prints 0 myObj.doSomething(); print myOtherObj.someValue; // prints 1, unexpectedly, because I never indicated that these objects had anything to do with each other

13 design  testing  architecture  singleton 

最近、シングルトンに対する何らかの革命がありましたが、それらがステートレスである場合、シングルトンに何か問題がありますか？ 私は酷使の話とすべてを知っています...これはシングルトンだけでなくすべてに適用されます。

12 design-patterns  object-oriented  singleton  immutability 

問題 私は最近、シングルトンが悪いことと、依存性注入（「インターフェースを使用する」と理解しています）がどのように優れているかについて、多くのことを読みました。コールバック/インターフェース/ DIを使用してこの一部を実装し、インターフェース分離の原則に準拠した場合、結局は混乱しました。 基本的にそのすべての子の依存関係を組み合わせたUI親の依存関係。したがって、UI要素が階層の上位にあるほど、そのコンストラクターは肥大化していました。 UI階層の最上位にあるのはApplicationクラスで、現在の選択に関する情報と、変更を反映する必要のある3Dモデルへの参照を保持していました。アプリケーションクラスは8つのインターフェイスを実装していましたが、これは製品（/インターフェイス）の5分の1に過ぎません。 私は現在、現在の選択を保持するシングルトンと、自分自身を更新する機能を持つUI要素を使用しています。この関数は、UIツリーとUI要素を細流化し、必要に応じて現在の選択シングルトンにアクセスします。コードはこのように私にはきれいに見えます。 質問 このプロジェクトにはシングルトンが適切でしょうか？ そうでない場合、私の考えやDIの実装に根本的な欠陥があり、それが非常に煩雑になりますか？ プロジェクトに関する追加情報 タイプ：ベルとホイッスル付きのアパートメントのショッピングバスケット サイズ：コードとUIに2か月/月 メンテナンス：実行中の更新はありませんが、後で「バージョン2.0」になる可能性があります 環境：エンティティを使用するUnityでC＃を使用コンポーネントシステム ほとんどすべての場合、ユーザーの操作によっていくつかのアクションがトリガーされます。たとえば、ユーザーがアイテムを選択したとき そのアイテムとその説明を表示するUIパーツを更新する必要があります。このため、価格を計算するために、3Dモデルから情報を取得する必要もあります。 UIをさらに上に行くと、全体の合計価格を更新する必要があります 3dモデルのクラスの対応する関数を呼び出して、そこに変更を表示する必要があります

9 c#  dependency-injection  singleton 

シングルトンパターンとそれがどのように「悪い」のかについては、クラスをテストするのが難しくなるので避けてきました。シングルトンを依存性注入に置き換える方法を説明した記事をいくつか読んだことがありますが、それは不必要に複雑に思えます。 これがもう少し詳しく私の問題です。私はReact Nativeを使用してモバイルアプリを構築しています。サーバーと通信し、データを取得し、データを投稿し、ログインを処理するRESTクライアントを作成します（ログイントークンを保存し、ログイン後にリクエストごとに送信します）。 私の最初の計画は、アプリが最初にログインに使用し、必要に応じて資格情報の送信を要求するシングルトンオブジェクト（RESTClient）を作成することでした。DIのアプローチは本当に複雑に思えます（おそらくDIを使用したことがないためです）が、このプロジェクトを最大限に活用して、ここで最善を尽くしたいと思います。提案やコメントは大歓迎です。 編集：私は今、自分の質問の言葉遣いが不十分であることに気づきました。RNでシングルトンパターンを回避する方法についてのガイダンスが必要でした。幸運にも、サミュエルは私が望んでいたような答えをくれました。私の問題は、シングルトンパターンを避けてDIを使用したかったのですが、React Nativeで実装するのは本当に複雑に思えました。さらに調査を行い、Reactsコンテキストシステムを使用して実装しました。 ここに興味のある人のために、私はそれをしました。私が言ったように、私はプロップのようなものであるRNのコンテキストを使用しましたが、それはすべてのコンポーネントに伝搬されます。 ルートコンポーネントでは、次のような必要な依存関係を提供します。 export default class Root extends Component { getChildContext() { restClient: new MyRestClient(); } render() {...} } Root.childContextTypes = {restClient: PropTypes.object}; これで、restClientは、ルートの下のすべてのコンポーネントで使用できます。このようにアクセスできます。 export default class Child extends Component { useRestClient() { this.context.restClient.getData(...); } render() {...} } Child.contextTypes = {restClient: PropTypes.object} これにより、オブジェクトの作成がロジックから効果的に離れ、RESTクライアントの実装がコンポーネントから切り離されます。

8 design-patterns  architecture  dependency-injection  singleton  react