シングルトンはカプセル化を使用しますか？
Gang of 4のデザインパターンの本を読んでいます。シングルトンはカプセル化を使用していますか？私にはそう思われるかもしれませんが、100％確信はありません。たぶん私はカプセル化についてよく理解していません。
「カプセル化」の一般的に合意された標準的な定義を私は知りませんが、少なくとも次のものが必要になると思います。
パブリックインターフェイスを介してオブジェクトを無効な状態（不変条件が壊れている）に変換できない場合、オブジェクトの内部はカプセル化されます。
シングルトンクラスのパブリックインターフェイスは、単一の静的関数getInstanceに加えて、シングルトンオブジェクトが実際に提供するインターフェイスで構成されます（これはパターンの一部ではありません）。 getInstance関数を使用して無効な状態にすることはできません。これは、デフォルトのコンストラクターを介してインスタンスを作成し、それをグローバル変数にキャッシュするだけだからです。クラスの実際の（有用な）インターフェースがカプセル化に従うかどうかは、その実装者次第です。 （デフォルトのコンストラクターはプライベートであるため、原則として無効な状態でオブジェクトを構築することは許可されますが、そうではないと仮定しましょう。）
クラスの残りの部分のカプセル化を考慮すると、シングルトンパターンは何も変更しません。または、 Robert Harvey がコメントに入れているように：
シングルトンは、クラスがまだ持っていないテーブルにカプセル化をもたらしません。クラスのカプセル化が不十分である場合、シングルトンに変換された後も、カプセル化は不十分です。シングルトンはクラスを単一のインスタンスに制限し、それがすべてです。
一方、クラスが最初に適切にカプセル化されている場合、それをシングルトンにしても、そのプロパティは破壊されません。ただし、シングルトンパターンは別の重要な原則に違反しています。 単一責任の原則。それは基本的に、各コンポーネントが1つの仕事をし、それをうまくやるべきだと言っています。 （多少異なる意見については、以下のコメントを参照してください。）シングルトンパターンは、クラスが実行するビジネスロジックと、そのインスタンスを作成するルールとその数を組み合わせます。これは、それとその消費者との間の結合を望ましいよりも強くし、特にテストを不必要に難しくします。今日、シングルトンは多くの人からアンチパターンと見なされています。それについて多くのことが言われているので、ここにトピックに関するグーグルのクリーンコードトークからの1つのビデオだけがあります： 「グローバルステートとシングルトン」 MiškoHevery 。