ここまで読んでくださった皆さんに、ちょっとしたクリスマスプレゼント。マンガでわかる GoF デザインパターン 23 種チートシートです。これでもうデザインパターンは完全にマスターしましたよ。やったね!

(注: ここからはあとがきポエムです)

ところでみなさん、せっかくデザインパターンを学んだので、これを使ってプログラムを書こう、チートシートがあるからなんでも書けそうだぞ、なんて思っていませんか。ダメですよ。そんなことしたら 2000 年前後に起きた失敗を繰り返してしまいます。

実は GoF のデザインパターンは、ビジネス的には成功したけど、教育には失敗しました。最初に出版された本に「オブジェクト指向における再利用のための」という肩書が付いていましたが、これが本当に良くなかった。

あの頃 (ポール・グレアムが LISP と Ruby を褒めるまで) は、「オブジェクト指向様こそが良い設計のすべて教」が信仰されていました。みんな、オブジェクト指向とは何かって意識がピンキリで、キリのみなさんは、これでコードを書くスキルを身につけて再利用できると考えてしまいました。

その結果何が起きたかというと、無目的なデザインパターンの乱用です。目的はわからないけど、デザインパターンを盛り込んだ方がソフトウェアが高級になるらしい、なんてとんでもない迷信がはびこったのです。目的のないパターンはただの難読化です。

いま日本では DDD (ドメイン駆動設計) が再燃していますが、そんな中、コードと業務を一致させる組織論を諦めたグループが、軽量 DDD と称して DDD のデザインパターンだけを利用しようとしています。たいへん危険な思想です。

DDD のデザインパターンは、ユビキタス言語を形成するための道具です。わかっていてやる最初の人はいいですが、そうとは知らない人がパターンだけを真似させられたらどうなるでしょう。疎結合にした先をビジネスの本質に一致させようとする意識がないまま、どうだクールなアーキテクチャだぜ、でいくと「依存方向を逆転してるのか何だか知らないけど、結局いつも全部修正させられるんだから、Repository で Entity に転送するより、愚直に ActiveRecord のままやって BDD した方がよっぽど簡単だった」「なんで開発そんなに遅いの」なんて言われかねません。(←本題じゃないので反論は別の機会に)

GoF の失敗の原因は、そんな、ドメインを失ったドメイン駆動パターンのように、そもそもの目的を見失っていたことです。本の題名に含まれていた「オブジェクト指向」が指していること、良い設計って何だったんでしょう??

継承よりコンポジションを好む方が柔軟になる (これは主張されてた)
操作から生成の関心を分離して条件分岐を減らす
状態の変更を最小限に → イミュータブルこそ最高
後で決めたいことから先に決めたいことに単方向依存させよ
(↑つまり SOLID 原則を手段としたパッケージ原則が目的)

これらを、経験ある人にとっては本能でわかることと思いますが、なんて文脈ひどない? 「C++ と Java を使って書くことがオブジェクト指向」と思っている初心者が、デザインパターン本とサンプルコードを突然目にして、これがナウいらしいと言われたらどう思うか...

なので、このマンガでわかるシリーズでは、プログラムの書き方にはいっさい言及しませんでした。大事なのは、かっこいいプログラムを書ききることではなくて、必要があって露出した設計 (安定度のムラと依存方向の問題など) 判断に対して、どれだけみんなへの説明を省けるかなのです。

再利用というのは、これさえ学べば何度でもプログラムを書くことができる、という意味ではなくて、「みんなの共通ボキャブラリにしていこうね」「もし自分の考えた設計がデザインパターンの形になるなら、ちょうどいいメタファーがあるんだから、そう呼べばみんなにわかりやすいよ」という意味だったんです。物を書くときの再利用ではなく、読むときのメンタルモデルの再利用が目的だった。

そのためには、あんな分厚い偉そうな本ではダメです。どこが要点かわからないぐらいに豊富すぎる Java のサンプルコードが載った本でもダメ。ぱっと見でそのパターンが「何であって」「何でないのか」がわかるコンテンツでなきゃという思いがありました。

HTTP ミドルウェアは Proxy パターンですね。CQRS とかいうアレの C はまさに Command です。たいていのフレームワークは Template Method パターンを利用しています。最重要パターン、Abstract Factory は、オブジェクト指向の醍醐味、操作と生成の分離の概念が難しかったのを、一言で表せるようにしてくれています。

流行りに乗ったけどうまく行かなかった人たちを尻目に、うまくやっていた一部の人々は、20 年の間にいろいろなソフトウェアを残してくれました。OSS にこれだけアクセスしやすくなったいま、パターンで読める知識がさまざまな所に見て取れます。初心者にとってのデザインパターンは、いまや本当に、書くものではなく、読み取るものになったと思います。

実は、マンガを描くためにウェブで調べているうちに、どのような有様を指すかではなく、どのように 書くこと がデザインパターンなのかを説明する記事があまりにも多くて、とても残念な気持ちになりました。時代だったからしょうがないですね。けどもう GoF は良い意味でオワコンなので安心してください!!

このシリーズを読んでくださった皆さんが、「なんだ、結局これじゃプログラムを書くのに使えないや」と思いながらも、パターンに関係するマンガのシチュエーションが記憶に残っていて、「あれ?なんかイメージと違う」と感じられるようになったなら、それこそ大成功だと思っています。パターンを組み合わせてプログラムを書くぞ、なんて思ってた時代より、よっぽど深く理解できたスタートラインに立ったことになるので。

繰り返します。デザインパターンを組み合わせてコードを書こうとしないでください。がんばって自分の設計センス (= いろいろ見てきた経験) に従って書いているうちに、あるいは他人のコードを読んでいるうちに、そこにパターンを見出せるようになってください。それをコミュニケーションに活かしてください。

見出したパターンの名前を借りて、チームに共通の語彙を形成しいくのです。プロジェクトで使える語彙だけ使えばいいんです。でも、使わないなら知らなくていい、じゃないです。知らなきゃ使える状況ですぐ出てこない。ことわざと同じです。学習コスト? マンガ読むのに学習コストかかります? 意味を知らない人がいても、マンガを読ませて「このイメージ」って教えればすぐですよね。

ちょうぜつアドベントカレンダーは 再利用可能な ~~オブジェクト指向~~ いい感じの設計のための ブログ記事です。

(はい、技術的内容にポエムをぶら下げる戦略でした)