2

シングルトンはアンチパターンなので悪いと思います。また、これの主な理由は、とにかくシングルトンへのグローバル参照であると読みました。

シングルトンを回避することは常に可能ですか?

もしそうなら、例えば私はIOCPネットワークを手に入れ、それを一度初期化する必要があり、このオブジェクトはソフトウェアの存続期間全体を通して一定である必要があるとしましょう。同じことが、私が「ペイント」と呼んでいる、データを画面に印刷するクラスに付属しています。シングルトンを作成しなかった場合でも、現在のHwndのグローバル変数が必要であり、オブジェクトを使用するたびにローカルでオブジェクトを初期化する必要があります(本当に面倒です)。

それで、シングルトンを使用することは、私の設計に欠陥があることを示していますか?それらを回避するために何ができますか?

ありがとう。

4

2 に答える 2

5

シングルトンを避けることは常に可能ですか?

はい、グローバル変数を使用するか、(さらに良いことに) デザインを修正してください。設計を修正する 1 つのオプションは、ある種の制御の反転を使用することです。

オブジェクト指向の原則を使用しようとすると、シングルトンなしでできることがわかります。

于 2012-09-20T06:28:28.343 に答える
0

どのエンティティがいつインスタンス化できるリソースにアクセスする必要があるかという問題です(以降、リソースと呼びます)。

このリソースへのアクセスを必要とするエンティティをリソース(IOC、依存性注入)でインスタンス化できる場合は、それが最善の方法であり、物事をシンプルに保ち、シングルトンの作成を回避します。KISS

何らかの理由で、リソースへのアクセスを必要としているが、リソースを使用してインスタンス化できないエンティティがある場合は、代替手段を実装する必要があります。1つのオプションはシングルトンですが、私が使用したいもう1つのオプションはファクトリーです。これにより、リソースの作成が完全にカプセル化され、将来性が大幅に向上します。つまり、将来、何らかの理由でリソースの複数のインスタンスをインスタンス化でき、そのすべてがカプセル化されます。シングルトンでこれを行うことはできません/すべきではありません。もちろん、内部的にはファクトリはリソースの一意のインスタンスを維持します。

エンティティがリソースでインスタンス化できない場合、設計が悪いと主張する人がいます。それは議論の余地があり、おそらくケースバイケースでそうすべきです。

于 2012-09-20T09:48:40.437 に答える