Rubyでのジャンクドロワークラスの回避

Rubyはオブジェクト指向言語であるため、世界をオブジェクトのセットとしてモデル化する傾向があります。 2つの整数（xとy）は点であり、線には2つあると言います。

このアプローチはしばしば有用ですが、1つの大きな問題があります。これは、データの1つの解釈を他のすべてよりも優先します。 xとyは常に点であり、セルまたはベクトルとして機能する必要はないことを前提としています。

セルが必要な場合はどうなりますか？ええと、Pointがデータを所有しています。したがって、セルメソッドをPointに追加します。時間の経過とともに、ゆるやかに関連するメソッドのジャンクドロワーであるPointクラスになります。

ジャンクドロワークラスは非常に一般的であるため、私たちはそれらを避けられないものとして受け入れ、開発への「リファクタリング」ステップに取り組むことがよくあります。しかし、そもそも問題を回避できたらどうでしょうか？

Web開発の最初のルールは、私たちが話し合わないことですユーザークラス

戦闘で強化されたプロダクションRailsアプリの中心には、Userと呼ばれるクラスの巨大な怪物があります。 。

それは常に無邪気に始まります。ユーザーにログインを許可したい。ユーザー名とパスワードを保存する必要があるため、クラスを作成します。

class User
  attr_accessor :username, :password, :email, :address

  def authenticate!(password)
    ...
  end
end

それは非常にうまく機能するので、最終的に人々はあなたにお金を与えたいと思うでしょう。 「わかりました。ユーザーは基本的にサブスクライバーと同じものなので、いくつかの属性といくつかのメソッドを追加するだけです。」

class User
    ...

    attr_accessor :payment_processor_token, :subscription_plan_id, ...etc

    def charge_cc
      ...
    end
end

すごい！今、私たちはいくつかの本当のお金を稼いでいます！ CEOは、営業チームが簡単にSalesForceにインポートできるように、ユーザーの連絡先情報を含むVCardをエクスポートできるようにすることを決定しました。 vimを起動する時間：

class User
    ...

    def export_vcard
      ...
    end
end

何をしましたか？

まず、認証を処理することだけを目的としたUserクラスから始めました。メソッドと属性を追加することで、ユーザー/サブスクライバー/連絡先のフランケンシュタインハイブリッドになりました。

なぜこれを行うのでしょうか？開発者としての自分を尊重しませんか？私たちの両親は私たちを十分に愛していませんでしたか？それとも、このデータが本当に であると信じて、失敗に備えたのでしょうか。 物、物？

ユーザー名、パスワード、メールアドレスの組み合わせがユーザーであると言うのはなぜですか？なぜ加入者ではないのですか？または連絡先？またはSessionHolder？

データについての真実は、それがデータであるということです

データは単なるデータです。今日、あなたはそれをボーイフレンドのように扱う必要があるかもしれません。明日は元カレかもしれません。

これは、Elixirのような関数型言語が採用するアプローチです。データは、Rubyのハッシュ、配列、文​​字列などのような単純な構造で格納されます。データを処理する場合は、データを関数に渡します。結果はその関数から返されます。

単純に聞こえますが、このアプローチにより、関心の分離を非常に簡単に異なるモジュールに分けることができます。

これは、Elixirでユーザーシステムを構築する方法の漫画です：

my_user = %{username: "foo", password: ..., phone: ..., payment_token: ...}
my_user = Authentication.authenticate(my_user)
my_user = Subscription.charge(my_user)
my_user = Contact.export_vcard(my_user)

データはコードとは別のものであるため、そのデータを特権的に解釈するモジュールはありません。

Rubyに戻す

このアプローチはElixirで非常にうまく機能するので、Rubyで採用してみませんか？ Userの作成を妨げるものは何もありません データの単純なラッパーに変換し、すべてのビジネスロジックをモジュールにプルします。

class User
  attr_accessor :username, :password, :email, :address
end

module Authentication
  def self.authenticate!(user)
    ..
  end
end

module Subscription
  def self.charge(user)
    ..
  end
end

module Contact
  def self.export_vcard(user)
    ..
  end
end

Userを作成することもできます 構造体にクラス化するか、コードを追加して（一種の）不変にします。

だから何？

これは些細な変化のように見えますか？ポイントは何ですか？

これまで見てきたように、典型的なOOアプローチには、経年変化に伴う問題があります。特定のクラスが所有していると言うことによって データの場合、そのデータを他の方法で使用する必要があるときに問題が発生します。

ただし、モジュラーアプローチでは、動作を追加しても問題はありません。必要な方法でデータを解釈する新しいモジュールを作成するだけです。データと機能が完全に分離されているため、これを行うのは簡単です。