「Rubyによるデザインパターン」の読書メモです

時々、個人の見解入りです。

序章

デザインパターンは、ソフトウェアを構築する際に繰り返し発生する一般的な問題を認識し、解決する手助けをするという意味があります。

第1章 よいプログラムとパターン

パターンのためのパターン

変わるものを変わらないものから分離する

理想的なシステムでは、すべての変更は局所的です。すべてのコードをくまなく調べる必要がないようにすべきです。

コードの流れを追うという意味では、そうだと思います。

同じプロダクトだけど、管理しているソースコードが違ったりすると、これは難しくなりそうです。

インターフェースに対してプログラムし、実装に対して行わない

この記事に似たようなことを書いた気がするので置いておきます。

オブジェクト指向について – ためすう

継承より集約

継承

継承は、まさにその性質から、サブクラスをスーパークラスに結びつける傾向があります。スーパークラスの振る舞いを変更すれば、それはサブクラスの振る舞いを変えてしまうことになります。

test1.rb

class Vehicle
  def start_engine
    p "#{self.class.name}:#{__method__}"
  end

  def stop_engine
    p "#{self.class.name}:#{__method__}"
  end
end

class Car < Vehicle
  def sunday_drive
    start_engine
    # ... something
    stop_engine
  end
end

Car.new.sunday_drive

集約

test2.rb

class Engine
  def start
    p "#{self.class.name}:#{__method__}"
  end

  def stop
    p "#{self.class.name}:#{__method__}"
  end
end

class Car
  def initialize
    @engine = Engine.new
  end

  def sunday_drive
    @engine.start
    # something...
    @engine.stop
  end
end

Car.new.sunday_drive

Engine クラスを切り出しました。

Engine の差し替えもやりやすくなります。

委譲、委譲、委譲

委譲先のオブジェクトに責任転嫁する際に、追加のメソッド呼び出しが必要になります。

=> Ruby ではそのようなメソッドは書かなくてもOK (詳しくは、第10章、第11章)

必要になるまで作るな

YAGNI 原則

「You Ain’t Gonna Need It (必要になるまで作るな)」

将来のことは誰にも分からないので、いつか必要になる可能性もあると同時に

必要にならない可能性もあります。

本書で扱うGoFの14パターン

• Template Method
• Strategy
• Observer
• Composite
• Iterator
• Command
• Adapter
• Proxy
• Decorator
• Singleton
• Factory Method
• Abstract Factory
• Builder
• Interpreter

さらに

• 内部ドメイン特化言語
  • 専門分野に特化した小さな言語を作るとても動的な仕組み
• メタプログラミング
  • 必要なクラスやオブジェクトを実行時に動的に作るテクニック
• Convention over Configuration (CoC)
  • 構成ファイル (たいていはXML)の憂鬱への治療薬