デザインパターン入門：GoFの23パターンをまとめて解説

デザインパターンとは

デザインパターンは、ライブラリでも、コピーして使うコードでもありません。繰り返し現れる問題、解決策の核心、そして採用したときのトレードオフを記述したものです。実際のコードは、使う言語やプログラムに合わせて自分で書きます。

GoFの書籍では、各パターンを次の4つの基本要素で説明しています。

• 名前：「Decoratorで包めばよさそうです」のように、設計について会話するための一言か二言の名称です。
• 問題：そのパターンをいつ適用するか、どのような状況で必要になるかを示します。
• 解決策：関わるクラスやオブジェクト、それぞれの責務、協調のしかたを示します。
• 結果：得られる利点と支払うコストです。たとえば、柔軟性が高まる代わりにクラスが増えます。

この考え方は建築に由来します。Christopher Alexander の著書『A Pattern Language』（1977年）は建物や街づくりで繰り返し使われる解決策を記述しており、GoFの著者たちは同じ発想をオブジェクト指向ソフトウェアに応用しました。

Gang of Four（GoF）の書籍

『Design Patterns: Elements of Reusable Object-Oriented Software』は1994年に Addison-Wesley から出版されました。サンプルコードはC++とSmalltalkですが、パターン自体はJava、C#、TypeScript、Python、Kotlinなど、あらゆるオブジェクト指向言語に応用できます。

カタログに加えて、この書籍は多くのパターンに共通する次の2つの一般原則を主張しています。

• 実装ではなくインターフェースに対してプログラミングする。コードは具体的なクラスではなく、オブジェクトが何をできるかに依存すべきです。
• クラスの継承よりオブジェクトの合成を優先する。オブジェクトを組み合わせて振る舞いを作るほうが、深いクラス階層を作るよりも、たいてい柔軟です。

また、この書籍は各パターンを適用範囲で分類しています。クラスパターンは継承を使い、コンパイル時に固定されます（Factory Method、クラス版Adapter、Interpreter、Template Method）。オブジェクトパターンは合成を使い、実行時に変更できます（それ以外のすべて）。

カテゴリ別・GoF全23パターン

生成パターンはオブジェクトをどう作るか、構造パターンはクラスやオブジェクトをどう組み合わせて大きな構造にするか、振る舞いパターンはオブジェクト同士がどう通信して責務を分担するかを扱います。

実践例：TypeScriptで見るStrategy

パターンが働く小さな例を見てみましょう。チェックアウト処理で、送料を複数の方法で計算する必要があります。増え続ける if/else の連鎖にする代わりに、各ルールを1つのインターフェースの背後にある交換可能なオブジェクトにします。

interface ShippingStrategy {
  cost(weightKg: number): number;
}
class FlatRate implements ShippingStrategy {
  cost(): number { return 5; }
}
class PerKilogram implements ShippingStrategy {
  cost(weightKg: number): number { return 2 * weightKg; }
}
class Checkout {
  constructor(private shipping: ShippingStrategy) {}
  setShipping(s: ShippingStrategy): void { this.shipping = s; }
  total(itemsPrice: number, weightKg: number): number {
    return itemsPrice + this.shipping.cost(weightKg);
  }
}
const checkout = new Checkout(new FlatRate());
console.log(checkout.total(40, 3)); // 45
checkout.setShipping(new PerKilogram());
console.log(checkout.total(40, 3)); // 46

TypeScriptでは関数も値なので、同じ設計をより少ないコードで書けます。これはよくあるテーマで、第一級関数を持つ言語では、多くのパターンが単純になったり、不要になったりします。

type Shipping = (weightKg: number) => number;
const flatRate: Shipping = () => 5;
const perKilogram: Shipping = (w) => 2 * w;
function total(itemsPrice: number, weightKg: number, shipping: Shipping): number {
  return itemsPrice + shipping(weightKg);
}
console.log(total(40, 3, flatRate));    // 45
console.log(total(40, 3, perKilogram)); // 46

パターンの選び方

パターンからではなく、問題から始めてください。パターンが増やすクラスに見合うのは、コードの現実の痛みを取り除くときだけです。次の問いが、よく使われる候補を示してくれます。

1. まず、動く最もシンプルなコードを書きます。
2. 同じ種類の変更で何度も困るようになったら（たとえば、決済手段を追加するたびに5つのファイルを修正する場合）、その問題に名前を付けます。
3. その問題に対処するパターンを調べ、結果（利点とコスト）を読みます。
4. 痛みを取り除ける最小限の形でパターンを適用し、そこで止めます。

批判と限界

デザインパターンは有用ですが、誤用されることも多くあります。よくある批判を知っておきましょう。

• 過剰な適用：「念のため」にファクトリ、インターフェース、マネージャを足すと、単純なコードが読みにくくなります。これはパターン熱とも呼ばれます。
• 言語機能の不足の補い：1996年に Peter Norvig は、23のGoFパターンのうち16個が、LispやDylanのような動的言語では目立たなくなるか、より単純になることを示しました。第一級関数はStrategyやCommandの代わりになり、組み込みのイテレータはIteratorの代わりになります。
• 特にSingletonは、グローバル状態として使うとアンチパターンと見なされることが多く、依存関係を隠し、テストを難しくします。
• カタログは1994年のものです。その後の実践では、依存性の注入（DI）、リポジトリ、Model-View-Controllerの各種変形など、書籍に載っていない有名なパターンも加わりました。

この書籍の変わらない価値は、共通語彙と、トレードオフを考える習慣にあります。「これはAdapterです」と言うだけで、二言で多くのことが他の開発者に伝わります。

関連する原則

パターンは、オブジェクト指向設計のSOLID原則とあわせて説明されることがよくあります。たとえば、StrategyとDecoratorは開放閉鎖の原則を守る直接的な方法で、Abstract Factoryは依存性逆転の原則を適用する一般的な方法です。原則を学ぶと、パターンがなぜその形をしているのかが理解しやすくなります。