デザインパターンとは

この章でやること

ここからは、デザインパターンです。この章は実装の前の案内図であるデザインパターンとは何で、なぜ学ぶ価値があり、そしてなぜ全部は覚えなくていいのかを押さえます。

定石には、名前がついている

前の演習を思い出してください。チャプター12で、支払い方法をインターフェースの部品にして注文から差し替え可能にしました。あの設計、あなたが初めて書いたように感じたかもしれませんが、実は30年以上前から名前がついています(Strategyパターン。あとで正式に再会します)。

これがデザインパターンの正体です。ソフトウェア設計で繰り返し現れる問題と、その定番の解き方のセットに、名前をつけたもの。 1994年に4人の研究者(通称 Gang of Four、GoF)が23パターンをカタログ化した本を出版し、それが業界の共通語になりました。

囲碁や将棋に定石・定跡があるのと同じです。自力でも発見できるが、先人が何千回も試して磨いた形を知っていれば、同じ道を手探りで歩き直さなくていい。そういう知の再利用です。

名前があることの価値

パターンの価値は、解き方そのもの以上に「名前がある」ことにあります。

① 会話が圧縮される。 コードレビューで「ここ、通知先が増えるたびに修正入るから、Observerにしませんか」の一言が通じる。名前がなければ、ホワイトボードで10分説明することになります。チーム開発では、設計の語彙=コミュニケーション速度です。

② コードが読めるようになる。 ライブラリやフレームワークのコードには、パターン名がそのまま顔を出します。createApp(ファクトリ)、addEventListener(オブザーバ)、adapter という名前のパッケージ。パターンを知っていると、初見のコードベースで「ああ、この形ね」と構造が見える瞬間が増えます。

③ AIの出力を評価できる。 これは現代ならではの理由です。AIにコードを書かせると、デザインパターンを使った構造が普通に出てきます。パターンを知らないと「動くけど何でこんな形?」のまま貼り付けることになり、知っていれば「ここでFactoryは過剰では?」と判断する側に回れます。AIがコードを書く時代、人間の仕事は書くことより設計の良し悪しを判定することに寄っていきます。パターンはその判定の語彙です。

この講座で23個やらない理由

最初に宣言した通り、この講座はGoFの23パターンを網羅しません。理由は怠慢ではなく、現代のJavaScript/TypeScriptでは事情が変わったからです。