抽象を見つけ、クラスを分ける

どのようにして抽象的なスーパークラスを見つけ、抽象と具象を分けていくかを考えて整理してみます。

車を例に抽象を見つける方法を考えてみます。例えば、全ての車が自家用車しかないアプリケーションにおいてはクラス名はCarで問題ありませんが、自家用車とバスの2つがある場合は変わってきます。

自家用車とバスはどちらも車の一種であり、それぞれ共通化できる抽象と特化できる具象に分けることができます。そしてこの自家用車とバスを車が特化したものとして捉えるのは、継承のルールである凡化-特化の関係として正しいと考えます。

こうしてスーパークラスである車と、そのサブクラスである自家用車とバスに分けることができます。

抽象的なスーパークラスをつくる

先程の継承から、以下のクラス図のようにCarがPrivateCarとBusのスーパークラスとなっています。

この継承構造によってCarが共通の振る舞いを持ち、PrivateCarとBusがそれぞれ特化した振る舞いを追加できます。

以下のコードでは、スーパークラスであるCarは共通のsizeを含み、サブクラスであるBusは特有のpaymentを含みます。

class Car
  attr_reader :size

  def initialize(args={})
    @size = args[:size]
  end

end

class PrivateCar < Car

  def initialize(args)
    super(args)
  end

end

class Bus < Car
  attr_reader :payment_style

  def initialize(args)
    @payment_style = args[:payment_style]
    super(args)
  end

end

テンプレートメソッドパターン

Carのinitializeメソッドにdefault_seat_colorとdefault_seat_numberというデフォルト値となる2つのメッセージを追加してみます。

これらのメッセージを用意しオーバーライドすることで、サブクラスに特化した状態や振る舞いを定義する機会を与えることができます。

スーパークラス内で基本の構造を定義し、サブクラスにメッセージを送る手法は、テンプレートメソッドパターンとして知られています。

以下のコードでは、サブクラス両方ともdefault_seat_numberを実装し、default_seat_colorはスーパークラスにのみ実装しています。それぞれのサブクラスは座席数に独自の初期値を用意するものの、座席の色はスーパークラスの共通の初期値を継承します。

class Car
  attr_reader :size

  def initialize(args={})
    @size = args[:size]
    @seat_color = args[:seat_color] | default_seat_color
    @seat_number= args[:seat_number] | default_seat_number
  end

  def default_seat_color
    ‘black’
  end

end

class PrivateCar < Car

  def default_seat_number
    4
  end

end

class Bus < Car
  attr_reader :payment_style

  def initialize(args)
    @payment_style = args[:payment_style]
    super(args)
  end

  def default_seat_number
    24
  end

end

これによって、全ての車において座席の色は同じ初期値が使われ、座席数はサブクラスによって異なる初期値が使われるようになりました。

全てのテンプレートメソッドを実装する

Carによるinitializeメソッドではdefault_seat_numberをサブクラスに送りますが、Car自体には実装れていません。そのため例えば新しくトラックを追加した場合、以下のような問題を引き起こす場合があります。

Class Truck < Car

  def default_seat_color
    ‘gray’
  end

end

truck = Truck.new(size: ‘M’)
# undefined local variable or method ‘default_seat_number’

これは、今後Carから新しくサブクラスを作っていくタイミングで発生しうるエラーです。この問題は一見コードを見るだけではわからない要件をサブクラスに課していることです。

Carにdefault_seat_numberが書かれている限り、サブクラスはdefault_seat_numberを必ず実装している必要があります。

この気付きにくい要件を前もって知らせるためには、テンプレートメソッドパターンを使うどのクラスにおいても、送信するメッセージの全てに実装を用意します。

以下のようにサブクラスがメッセージを実装する必要があるとスーパークラスに明示的に示すことで、開発者は要件に気付くことができます。例え実装時に気づかなくても明確なエラーメッセージを用意することで、実行時に開発者はそのエラーメッセージから気付くことができます。

Class Car

  …

  def default_seat_number
    raise NoImplementedError
      “This #{self.class} cannot respond to:”
  end

end

参考：

ダックタイピングとは

ダックタイピングとは、Rubyなどの動的型付けオブジェクト指向プログラミング言語で使われる型付けのやり方のことです。

この名前は「もしオブジェクトがダックのように鳴き、ダックのように歩くのならば、そのクラスが何であれ、それはダックである」と言う表現に由来しています。つまり、その何かが穴を掘ろうが、ジャンプしようが、ダックのように鳴き、歩くのであれば、それはダックとして扱うことができるということだと解釈しました。

実際にコードに落とし込んで考えた際、ダックタイプはどの特定のクラスとも紐付かないインタフェースを定義することになると考えました。

ダックタイピングの使い所と具体例

実際にRubyでダックタイピングの使い所を考えてみます。

具体例として特典クラスがあり、会員によって提供する特典が変わるとします。会員を引数にcase文を使って提供する特典を判定しています。

この状態だと、会員メンバーのランクが増える度に、case文を追加しなくてはならず、システムが複雑化していく要因になります。

class Benefit
  attr_reader :gift_certificate, :souvenir, :coupon

  def find_benefit(members)
    members.each do |member|
      case member
      when PlatinumMember
        employee.prepare_gift_certificate(gift_certificate)
      when GoldMember
        employee.prepare_souvenir(souvenir)
      when StandardMember
        employee.prepare_coupon(coupon)
    end
  end
end

ダックタイプを意識して設計し直すと、以下のようになります。それぞれの引数のクラスは、新しいインターフェースを実装しています。

また、それぞれのランククラスが応答できるfind_benefitを追加することで、オブジェクトごとに振る舞いを変えることができます。

このprepare_benefitメソッドは、新たにランクを追加した際でも変更されることがありません。

class Benefit
  attr_reader :gift_certificate, :souvenir, :coupon

  def prepare_benefit(members)
    members.each do |member|
      member.find_benefit(self)
    end
  end
end

class PlatinumMember
  def find_benefit(benefit)
    prepare_gift_certificate(benefit.gift_certificate)
  end
end

class GoldMember
  def find_benefit(benefit)
    prepare_souvenir(benefit.souvenir)
  end
end

class StandardMember
  def find_benefit(benefit)
    prepare_coupon(benefit.coupon)
  end
end

ダックタイピングとポリモーフィズムの関係性

ダックタイピングを学んでみて、真っ先に思い浮かんだのはポリモーフィズムでした。ポリモーフィズムはあるが、ダックタイピングがないJavaなどの言語もあり、ダックタイピングはポリモーフィズムを実践するための一つの手段のように思いました。

実際に本記事の参考である、「オブジェクト指向設計実践ガイド」でもポリモーフィズムの話が登場し、一つの方法と説いています。

とはいえ、ダックタイピングとポリモーフィズムの関係性について調べていると、ポリモーフィズムはインターフェースによる明示性を必要をするものだからダック・タイピングは違うと説いている意見もあり、若干混乱しています。。

ダックタイピングというより動的型付け言語における課題点

ダックタイピングを学んで、より動的型付け言語における型による実行時エラーの課題点が浮き彫りになったように思いました。

ダックタイピングはオブジェクト指向設計における柔軟性と変更のしやすさを高めるが、静的型付け言語のように型を明確に定義しないが故に、実行するまで型エラーに気づくことが難しい点があります。特に大規模の開発や複雑なシステムにおいて大きな障害になるのではないかと思いました。

参考：

初期化の際に引数にハッシュを使う

固定されたパラメータの代わりにオプションのハッシュを受け取れるように実装します。

initializeメソッドは引数をただ1つのargsのみにしています。argsはハッシュであり、入力の全てが含まれます。そのため、引数の順番に対する依存が全て取り除かれ、初期化の際に使われる引数やデフォルト値の追加や削除がしやすくなります。

class Character

  attr_accessor :hp, :offensive_power, :defense_power

  def initialize(args)
    @hp = args[:hp]
    @offensive_power = args[:offensive_power]
    @defense_power = args[:defense_power]
  end
end

character = Character.new(:hp => 100, :offensive_power => 20, :defense_power => 5)

||メソッドでデフォルト値を設定する

||メソッドを使って明示的にデフォルト値を設定することができます。

注意点として、||メソッドはor演算子と同様の動作をするため、左辺の式がfalseまたはnilの場合右辺の結果を返します。

...

def initialize(args)
  @hp = args[:hp] || 50
  @offensive_power = args[:offensive_power] || 5
  @defense_power = args[:defense_power] || 2
end

...

例えば以下のような式の場合は、boolキーが存在しない時、または存在するが値がfalseまたはnilの場合でもtrueが設定されるようになってしまいます。

@bool = args[:bool] || true

fetchメソッドでデフォルト値を設定する

そのため、引数のfalseとnilの区別が必要な場合はfetchメソッドをデフォルト値の設定として使うのが良さそうです。fetchメソッドは対象のキーをみつけるのに失敗しても自動的にnilを返しません。

以下の例の場合、fetchメソッドを使うことでhpキーがargsハッシュにない場合のみ、デフォルト値の50が設定されるようになっています。||メソッドの違いは、hpに対してfalseやnilを設定することができます。

...

def initialize(args)
  @hp = args.fetch(:hp, 50)
  @offensive_power = args.fetch(:offensive_power, 5)
  @defense_power = args.fetch(:defense_power, 2)
end

...

参考：オブジェクト指向設計実践ガイド