70-シングルトンパターンの誘惑に負けない

「プログラマが知るべき97のこと」の70個目のエピソードは、シングルトンパターンに関する話です。シングルトンパターンはGoFのデザインパターンの中でも最もよく知られ、使われているパターンかと思います。その理由はシンプルであり、かつ強力で、かつ解りやすいからではないでしょうか？しかし、シングルトンパターンは簡単に使える反面で、陥りやすい弊害も多くあります。このエピソードではそのような弊害をいくつか紹介しています。特にユニットテストしにくくなるのが最大の欠点です。
例えば、アプリケーションの設定などを保持するオブジェクトはシングルトンパターンにしがちなオブジェクトです。アプリケーションの中で「１つしかない」と考えるのは自然なことでしょう。しかし、ユニットテストの時やデバッグ時などは、設定オブジェクトを差し替えたいと考えます。シングルトンであるが故に差し替えできないという状況を生んでしまいます。
また、グローバル変数のような使い方をシングルトンオブジェクトに行うコードも見かけます。シングルトンオブジェクトが至るところから参照され、かつ状態を変更できるとしたら恐ろしいことです。それは、あの忌み嫌われているグローバル変数と同じです。参照されているところが増えていくと変更する事も難しくなりますし、マルチスレッド環境では問題はさらに深刻になります。ソースコードを読んでいてシングルトンパターンだらけのコードは非常に読みにくいものです。コードは至る所に依存関係を持ち、どうやっても引きはがせないほど癒着しいます。正直なところ、手遅れとなってしまうと、ユニットテストを諦めたり、多大な労力をさく必要になります。
勿論、気をつけてシングルトンパターンを適用すれば問題ありません。ただし、そのオブジェクトが１つしかないことが本当に妥当な判断かどうかを再確認した上で使うべきでしょう。また、欠点も持つということを認識すべきです。他のデザインパターンも同様ですが、適用する箇所を正しく判断し、デザインパターンを使いたいという事がデザインパターンを適用する理由にならないように注意しましょう。

プログラマが知るべき97のこと