Rubyでシングルトンパターンを実装する方法と、多くの場面で避けるべき理由

インスタンスを1つしか持たせられないクラスを作りたいと思ったことはありませんか？

はい？いいえ？あるいは…？

実は、それこそがシングルトンパターンの正体です。

このパターン自体に問題があるわけではありません。

しかし、悪い設計への言い訳として安易に使われがちなため、「アンチパターン」と呼ぶ開発者も少なくありません。

まずはコード例を見ながら、その仕組みを学んでいきましょう。

シングルトンパターンのコード例

シングルトンパターンの基本的な考え方は、クラスのインスタンスを1つだけに制限することです。

実装方法は次の2ステップです：

• newメソッドをprivateにして外部からの生成を防ぐ
• クラスの唯一のインスタンスを返すinstanceというクラスメソッドを定義する

このパターンは非常にポピュラーなため、Rubyの標準ライブラリにはSingletonモジュールが用意されており、どのクラスにもincludeできます。

実際のコードはこうなります：

require 'singleton'

class Shop
  include Singleton
end

この状態でShop.newのようにオブジェクトを生成しようとすると、次のようなエラーが発生します。

Shop.new
# NoMethodError: private method `new' called for Shop:Class

唯一のShopオブジェクトを取得したいときは、instanceメソッドを使います。

Shop.instance.object_id

# 5659218

Shop.instance.object_id

# 5659218

object_idが何度呼び出しても変わらないことから、常に同じオブジェクトが返されていることが確認できます。

覚えておきたいポイント：

これはシンプルなパターンで、オブジェクトの生成を1つに制限し、必要なときにいつでもそのオブジェクトへアクセスできるようにするものです。

このパターンを使うべきでない理由

シングルトンパターンは、事実上のグローバル変数を持つための言い訳として使われることがよくあります。グローバル変数は制御が難しく、テストを書きづらくし、モジュール間の結合度（カップリング）を高めることで悪名高い存在です。

「シングルトンの本当の問題は、オブジェクトの適切な可視性について慎重に考える機会を奪う、あまりにも都合のいい言い訳を与えてしまう点にある。」 – Kent Beck

アプリケーション内のほとんどのクラスが1つのオブジェクトに依存している状況を想像してみてください。それこそがシングルトンパターンが陥りがちな姿です。そんな状態のコードをリファクタリングするのは一苦労です。

さて：

このパターンに有効な使い道はないのでしょうか？

GitHubで検索してみると、Nullオブジェクトパターンと組み合わせてシングルトンパターンを活用しているリポジトリがいくつか見つかりました。

確かにそれは理にかなっています。実際、RailsもActionPackの一部でこの手法を採用しています。

以下がそのコードです：

class AllType < Type
  include Singleton

  def initialize
    super "*/*", :all
  end

  def all?; true; end
  def html?; true; end
end

これはTypeクラスを継承したクラスです。

instanceメソッド経由でAllTypeオブジェクトを初めて取得するときにはinitialize内のsuperが呼ばれ、オブジェクトが生成されて返されます。

それ以降にinstanceを呼び出すと、毎回同じオブジェクトが返される仕組みです。

まとめると：

適切な場面で使えば有用なパターンではありますが、十分に設計を検討せずに安易に導入するのは避けるべきでしょう。

まとめ

本記事では、シングルトンデザインパターンの概要、Rubyでの実装方法、そして多くの場面で避けるべき理由について解説しました。

このパターンについてどう思いますか？実際に使った経験はありますか？ぜひコメント欄でお聞かせください🙂

最後までお読みいただきありがとうございました！