Rubyによるデザインパターン第1章。デザインパターンとはプログラミングにおいて繰り返し現れる問題に対する、適切解のパターン。無駄無く設計されたオブジェクト指向プログラムの実現をサポート。なるまで作るな(YAGNI)変わるものを変わらないものから分離するソフトウェアの仕様には必ず変更が加わるもの。「仕様の変更」に対して「システムの変更」を出来る限り局所的にする。プログラムはインターフェイスに対して行う(実装に対して行わない)可能な限り「一般的・抽象的なもの」に対してプログラミングすること。(ここで言うインターフェイスは、Javaの組み込み構文としてのインターフェイスではなく、より広いレベルで「抽象度を高めたもの」を意味する。)これにより、全体のコードの結合度を下げる。my_plane.fly(200)end乗り物が増える度にコード全体に変更が必要(変更に弱い)。get_vehiclemy_vehicle.travel(200)乗り物の数が増えても本コードに変更を加える必要はない(変更に強い)。継承は望ましくないつながりを作ってしまう。具体的にはサブクラスの振る舞いは、スーパークラスの振る舞いに依存する。サブクラスからスーパークラスの中身を覗くことが出来る。→変わりやすい部分(Engine)を変わりにくい部分(Vehicle)から分離できていない。オブジェクトに、「他のオブジェクトに対する参照」を持たせる。何かを持っている(has-a)関係にする。endendこれでEngineがVehicleから分離され、またカプセル化された。これにより、Engineの手軽な切り替えが可能に。(delegation)(継承パターンと同じように)start_engineとstop_engineをクラスの外に公開したいこともある。そんな場合でも、処理の実態はEngineクラスに任せてしまう。endendこれで「継承より集約」を実現しつつ、継承時と同じ機能を持つクラスが作成できた。集約と委譲の組み合わせは、強力かつ柔軟な継承の代替手段。start_engineやstop_engineは委譲のために書かなければならない無駄なコードに思えるが、method_missing等の利用で解決できる。これはProxyパターンで別途詳細する。It.)「将来使うかも」は、大抵使わない。いたずらに柔軟性を持たせようとオーバーエンジニアリングしてコードの複雑性を増していては、本末転倒。デザインパターン自身は目的ではない。問題を解決し、目的を達成するための手段として役立てるべきであり、それ以上のものではない。デザインパターンを考える上での戒め。以上5原則を前提に各パターンを見ていく。