はじめに

Amazon: https://www.amazon.co.jp/dp/4048678841

第6章から第11章まではリファクタリングの具体的なテクニックがまとめられています。
今回は リファクタリング: Rubyエディション の 第11章一般化の処理 で紹介されているいくつかのテクニックについて、まとめました。

※ 以下のサンプルコードは書籍で紹介されているコードを参考に、自分で作成したコードを載せています。（著作権を侵害しないように）

テクニック一覧

テクニック詳細

Pull Up Method

どのサブクラスでも同じ結果になるメソッドがあるときに、メソッドをスーパークラスに移すテクニック

サンプル


# リファクタリング前
class Room
end

class SingleRoom < Room
  def base_price(date)
    date * 3000
  end
end

class SweetRoom < Room
  def base_price(date)
    date * 3000
  end
end

# リファクタリング後
class Room
  def base_price(date)
    date * 3000
  end
end

class SingleRoom < Room
end

class SweetRoom < Room
end

重複するメソッドがあると、片方を修正して、もう片方を修正し忘れるというリスクを抱えることになります。つまり、将来のバグの温床になる可能性が少なくありません。

同じクラスを継承するサブクラスに、同じ処理を実行するメソッドがあるときは、メソッドをスーパークラスに移動することで重複を取り除き、バグを産むリスクを低くしましょう。

Push Down Method

スーパークラスのメソッドが一部のサブクラスでしか使われていないとき、メソッドをサブクラスに移すテクニック

サンプル


# リファクタリング前
class Employee
  def bonus
    monthly_salary
  end
end

class PartTimeEmployee < Employee
end

class FullTimeEmployee < Employee
end

# リファクタリング後
class Employee
end

class PartTimeEmployee < Employee
end

class FullTimeEmployee < Employee
  def bonus
    monthly_salary
  end
end

Pull Up Method とは逆のテクニックで、スーパークラスのメソッドが一部のサブクラスでしか使われていないときは、そのメソッドをサブクラスにさせます。

上記のサンプルだと、スーパークラスに bonus メソッドを定義していては、 PartTimeEmployee(アルバイト) に対しても、ボーナスを支給する会社だと誤解を与えてしまいそうですね。

Extract Module

複数のクラスに重複するメソッドがあるときに、モジュールをインクルードするようにして、そのモジュールにメソッドを移すテクニック

サンプル


# リファクタリング前
class Deposit
  attr_accessor :account_id

  def capture_account_id(account)
    self.account_id = account.id
  end
end

class Withdraw
  attr_accessor :account_id

  def capture_account_id(account)
    self.account_id = account.id
  end
end

# リファクタリング後
module AccountIdCapture
  def capture_account_id(account)
    self.account_id = account.id
  end
end

class Deposit
  include AccountIdCapture
  attr_accessor :account_id
end

class Withdraw
  include AccountIdCapture
  attr_accessor :account_id
end

Pull Up Method で先述しましたが、メソッドの重複は将来のバグの温床になりかねません。このテクニックも、そういった重複を取り除くためのテクニックです。

Pull Up Method とは違い、サブクラス・スーパークラスの関係に限らず、複数のクラスでメソッドが重複してしまっているときに、適用するとよいテクニックです。

ただ気をつけなければならないのは、モジュールはグループとして意味を持つものでないといけないということです。モジュールが特定の意味をもつグループではなくなると、ただメソッドをかき集めた入れ物になってしまい、モジュールが膨れ上がり、どこに何のメソッドがあるかわからなくなってしまいます。

これではリファクタリングの目的である、効率の良い開発ができなくなってしまいますね。

Inline Module

モジュールがメソッドの重複を避ける役割を果たしていないときに、モジュールをインクルードしているクラスにメソッドを移すテクニック

サンプル

# なし

これは Extract Module とは逆のテクニックになります。モジュールをインクルードするということは、メソッドを探すときに、クラスを見て、そこになければインクルードしている関連のありそうなモジュールを特定し、そのモジュールの中を見るという手間が発生してしまいます。

もしモジュールが重複を避けるという役割を果たしていなかったときは、手間が増えるだけになってしまいます。そういったときはモジュールをインクルードしているクラスに、モジュール内のメソッドを移して、効率良く開発できるようにしましょう。

Extract Subclass

クラスが一部のインスタンスしか使わないフィールドをもっているときに、サブクラスを作ってリファクタリングするテクニック

サンプル


# リファクタリング前
class JobItem
  attr_accessor :unit_price, :quantity, :is_development_tool, :engineer

  def initialize(unit_price, quantity, is_development_tool, engineer)
    @unit_price = unit_price
    @quantity = quantity
    @is_development_tool = is_development_tool
    @engineer = engineer
  end

  def unit_price
    is_development_tool? ? unit_price * @engineer.rate : @unit_price
  end

  def is_development_tool?; @is_development_tool end
end

# リファクタリング後
class JobItem
  attr_accessor :unit_price, :quantity

  def initialize(unit_price, quantity)
    @unit_price = unit_price
    @quantity = quantity
  end
end

class DevelopmentItem < JobItem
  attr_accessor :engineer

  def initialize(unit_price, quantity, engineer)
    super(unit_price, quantity)
    @engineer = engineer
  end

  def unit_price
    @unit_price * @engineer.rate
  end
end

このテクニックを適用するきっかけとしてもっとも大きいのは、クラスの一部のインスタンスしか使わないメソッドやフィールドがあるとわかったときです。

上記のサンプルは、開発用ツールに関してはエンジニアの階級による割引価格で購入できるという前提でコードを書いています。リファクタリング前のコードだと、 is_development_tool が　true のときだけ、 engineer の情報が必要になります。

JobItem クラスに開発用ツールときだけ使用される、フィールドやメソッドがあることになります。こういった場合に、 Extract Subclass を適用して、サブクラスを抽出すれば、コードを綺麗にすることができますね。

Introduce Inheritance

似た機能を持つ2つ(複数)のクラスがあるときに、片方のクラスをスーパークラスにし、共通するフィールド・メソッドを移すテクニック

サンプル


# リファクタリング前
class Room
  attr_accessor :visitor, :base_price, :days

  def initialize(visitor, base_price, days)
    @visitor = visitor
    @base_price = base_price
    @days = days
  end

  def visitor_name
    @visitor.name
  end

  def total_price
    @base_price * @days
  end
end

class SweetRoom
  attr_accessor :visitor, :base_price, :days, :room_service_fee

  def initialize(visitor, base_price, days, room_service_fee)
    @visitor = visitor
    @base_price = base_price
    @days = days
    @room_service_fee = room_service_fee
  end

  def visitor_name
    visitor.name
  end

  def total_price
    @base_price * @days + @room_service_fee
  end
end

# リファクタリング後
class Room
  attr_accessor :visitor, :base_price, :days

  def initialize(visitor, base_price, days)
    @visitor = visitor
    @base_price = base_price
    @days = days
  end

  def visitor_name
    @visitor.name
  end

  def total_price
    @base_price * @days
  end
end

class SweetRoom < Room
  attr_accessor :visitor, :base_price, :days, :room_service_fee

  def initialize(visitor, base_price, days, room_service_fee)
    super(visitor, base_price, days)
    @room_service_fee = room_service_fee
  end

  def total_price
    super + @room_service_fee
  end
end

このテクニックも重複を避けるためのテクニックです。何度もしつこいようですが、重複するコードがあると不具合が発生する可能性が高くなります。

似たような機能をもつ2つのクラスがあるときに Introduce Inheritance を適用すれば、コードを重複を避けることができます。メソッド名が同じで中身が若干違うメソッドも super メソッドを使うことでシンプルに書けるかもしれません。

Collapse Hierarchy

スーパークラスとサブクラスに大差がないとき、両者を1つにするテクニック

サンプル

# なし

開発を進み、気がつくとスーパークラスとサブクラスに大した差分が無くなっていたりすることがあるようです（私はまだ経験したことがありませんが。。）

それに気付いたときに放置するのではなく、両者を1つにしてしまいましょう。クラスが少なくなれば見る箇所も少なくなるので、効率よく開発ができるようなるはずです。

考察

11章では、コードの重複を避けるべきだという主張が何度もされています。重複したコードがあると、片方は修正したのに、もう一方を修正し忘れる可能性が高まり、不具合を発生する可能性を高めます。

また重複するコードがある箇所を修正するたびに、様々なファイルを探し回るという手間もかかってしまい、効率のよい開発の妨げとなってしまいます。

つまり、開発効率を向上するため、不具合を未然に防ぐために、重複しているコードをいかに一箇所にまとめるかが大切なのだと考えます。

関連