だから私はシングルトンのクラスを掘り下げました、そしてそうです、私はそれらが非常に役立つと思います。私は主に複数のターゲット（ビュー、テーブルなど）のデータストレージにシングルトンを使用しています。そうは言っても、私はすでに自分のプロジェクトに多くのシングルトンを実装しようとしているのを見ることができます。
しかし、多くのシングルトンが悪影響を与える可能性はありますか？シングルトンについて私が読んだことから、プロセスでそれらごとに1つのインスタンスを作成するということです。他のクラスインスタンスは（適切に解放されると仮定して）メモリから解放されますが、シングルトンも解放する必要がありますか？
それで、それを1つの質問に絞り込むために：シングルトンがたくさんあることは有害ですか？
シングルトンはスケーリングしません。シングルトンであるべきだと思っていても、システムが大きくなると、複数が必要であることがわかります。
複数必要にならない場合は、シングルトンで十分です。ただし、システムの拡張に伴い、通常、独自のコンテキスト内で複数のものが必要になります。
シングルトンは、単に「グローバル」と言う別の方法です。悪くはありませんが、一般的に、システムが進化して複雑さを増すのは良い考えではありません。
GOFブックから：
シングルトンパターンにはいくつかの利点があります。
唯一のインスタンスへの制御されたアクセス。シングルトンクラスはその唯一のインスタンスをカプセル化するため、クライアントがいつどのようにアクセスするかを厳密に制御できます。
名前スペースの削減。シングルトンパターンは、グローバル変数を改良したものです。唯一のインスタンスを格納するグローバル変数で名前空間を汚染することを回避します。
操作と表現の改良を許可します。シングルトンクラスはサブクラス化されている可能性があり、この拡張クラスのインスタンスを使用してアプリケーションを簡単に構成できます。実行時に必要なクラスのインスタンスを使用してアプリケーションを構成できます。
可変数のインスタンスを許可します。このパターンにより、気が変わってシングルトンクラスの複数のインスタンスを許可することが簡単になります。さらに、同じアプローチを使用して、アプリケーションが使用するインスタンスの数を制御できます。シングルトンインスタンスへのアクセスを許可する操作のみを変更する必要があります。
クラス操作よりも柔軟性があります。シングルトンの機能をパッケージ化する別の方法は、次の方法です。シングルトンクラスはサブクラス化できます。クラス操作（つまり、C ++の静的メンバー関数またはSmalltalkのクラスメソッド）。ただし、これらの言語手法はどちらも、クラスの複数のインスタンスを許可するように設計を変更することを困難にします。さらに、C ++の静的メンバー関数は仮想ではないため、サブクラスはそれらを多態的にオーバーライドできません。