オブジェクト指向プログラミングにおいて有名な「シングルトンパターン」。開発初学者からベテランエンジニアまで、一度は耳にしたことのあるデザインパターンではないでしょうか。
「シングルトン」は、あるクラスに対してアプリケーション全体で唯一のインスタンスしか存在しないことを保証するパターンです。一見、「グローバルな共有オブジェクトがあれば便利そう！」と思うかもしれませんが、実は長期的な視点で見た時、シングルトンはしばしば「アンチパターン」として扱われます。
なぜシングルトンパターンが避けられる傾向があるのか。その理由について、今回は分かりやすく解説していきます。
シングルトンがアンチパターンとされる理由
1. 将来的な拡張に弱い「柔軟性の欠如」
シングルトンは「このオブジェクトは1つだけ」とクラス内部で決め打ちする設計です。そのため、後から新たな要求が生まれ、複数インスタンスが必要になった場合、コード全体を大幅に書き直す羽目になります。
例えば、当初は「ウィンドウは一つしか開かない」前提でウィンドウ管理クラスをシングルトンで実装したとしましょう。ところが後で「マルチウィンドウ対応したい」という要件が出てきたらどうなるでしょう？
シングルトン前提の作り込みによって、あちこちで Window.getInstance() のような呼び出しが散在しています。これらを全て「複数ウィンドウを扱えるような形」に書き換えるには、相当なリファクタリングが必要です。「単一インスタンス」という思い込みが、将来的な変更に対する柔軟性を奪ってしまうのです。
2. テストが難しくなる「依存関係の不透明化」
シングルトンはグローバルな状態を提供するため、コード中のどこからでもアクセスできるようになります。この一見便利な点が、テストを書く際に大きな障害となります。
通常、テスト容易性を高めるには「依存するオブジェクトを引数で受け取る」ことが重要です。なぜなら、テスト時にモックオブジェクトやテスト用の代替実装を簡単に差し替えることができるからです。
しかし、シングルトンを利用すると、テスト対象のクラスは内部的にグローバルなシングルトンオブジェクトへ依存し、そこを書き換えたり差し替えたりするのが困難になります。結果的に、テストが難しくなり、バグの特定や品質向上が妨げられてしまいます。
3. スレッドセーフティ対応の複雑化
アプリケーションがマルチスレッドになってくると、シングルトンはさらに頭痛の種になります。
唯一無二のインスタンスに複数のスレッドが同時にアクセスすると、状態管理で競合やデッドロックを引き起こしかねません。シングルトンをスレッドセーフに保とうとすると、複雑な同期処理が必要です。しかし、スレッドによって動作が変わるような設計は保守が難しく、潜在的なバグを生みがちです。
一方、シングルトンを避け、必要なときに必要な数のオブジェクトを生成する設計であれば、並列処理を前提とした実装も柔軟になります。スレッド安全性を考慮したオブジェクトや、逆に軽量でスレッド同期の不要なオブジェクトを選択でき、設計の自由度が高まります。
代替策：依存関係を明示的に渡す設計へ
シングルトンを使わず、必要な場所で必要なインスタンスを生成し、コンストラクタやメソッドの引数として依存性を明示的に渡すアプローチを取れば、多くの問題を回避できます。
// シングルトンを使わない良い例
public class CloseButtonHandler implements ButtonHandler {
private final Window window;
public CloseButtonHandler(Window window) {
this.window = Objects.requireNonNull(window);
}
@Override
public void buttonPressed() {
window.closeWindow();
}
}
このようにすれば、もし後でウィンドウを増やしたい場合でも、
- CloseButtonHandler に対して別の Window インスタンスを渡すだけで済む
- テスト時にはテスト用の Window 実装を注入することも簡単
となります。
「依存関係が多すぎる！引数が増え過ぎる！」という悩みがある場合は、以下の対処が可能です。
- 真に必要な依存関係だけを渡しているか、再考する
- ファクトリやビルダーを利用して複数の依存オブジェクトをまとめる
- DaggerなどのDIフレームワークで依存注入を自動化する
これらの手法によって、明確な依存関係管理を行いつつ、将来的な変更にも柔軟に対応できます。
まとめ
シングルトンパターンは一見シンプルで便利に見えますが、
- アプリケーションの成長や拡張による柔軟性不足
- テスト容易性の低下
- マルチスレッド対応の困難さ
といった問題を抱えています。
そのため、シングルトンはしばしば「アンチパターン」として避けることが推奨されます。代わりに、依存関係を明示的に受け渡し、必要であれば依存注入ツールを活用することで、コードの可読性・保守性・テスト容易性が大幅に向上します。
「将来の変更に強く、テストしやすいコード」を目指すなら、シングルトンに安易に飛びつくのではなく、依存関係を明確に、柔軟に扱える設計を検討してみてください。
参考文献