デザインパターンの使いどころ
Martin Fowler の Writing Software Patterns を取得して読み、 理解した内容を自分の言葉で書いたもの。本文の引用はしていない。
出典はパターンを「書く」側の文章だが、ここでは「読む・使う」側に読み替えている。 書き手に課される条件が、そのまま読み手が要求してよい条件になるため。
GoF のカタログそのものは書籍なので、このリポジトリの規約では扱えない。 ここで扱うのはカタログの中身ではなく、カタログとの付き合い方。
パターンとは何か
「文脈における問題への解」という定義は役に立たない、と Fowler は退ける。
代わりに置くのが知識を塊に分ける(chunking)道具という見方。
ソフトウェアを書くのに必要な知識は膨大なので、全部を覚えるのではなく、 必要なときに必要な塊を取り出せる形に分けておく。 そして分ける焦点になるのが「解」の側。
技法とパターンの違い
3つ揃って初めてパターンになる。
| 再現する | 多くの異なる状況で使える。 一度きりの解決は語彙に入れる価値がない |
| 名前がある | 名前が職業上の語彙になる |
| 核が同じ | 表面の実装が違っても、解の核が共通している |
「うまくいった実装」はパターンではない。 再現しなければ、名前を付ける意味がない。
「使わない場面」が本体
ここが、このリポジトリで一番使える指摘。
パターンだと思ったら、それを使わないのはどんなときかを考える。
これをやると2つ得られる。 対立候補のパターンに行き着くことと、元のパターン自体の理解が深まること。
Fowler は**「一組の選択肢しか記述しないパターン言語」を批判している。** ソフトウェアは多様な文脈で動くので、状況次第で複数の解が正しい。
だから読み手としての判断基準が立つ。
「いつ使わないか」が書かれていないカタログは、道具箱であって設計の助けにならない。 そういうものを読むときは、使わない条件を自分で補ってから使う。
必須の要素
書き手に求められる4つは、そのまま読み手が探すべき4つになる。
| 要素 | 中身 |
|---|---|
| 名前 | 喚起力のある名詞句。2〜3語が目安 |
| 問題と文脈 | 適用する理由と、しない理由の両方(forces) |
| 解 | 形式に凝っても、パターンは第一に解の話 |
| 帰結 | どういう状況に向くか、代わりに何があるか |
名前の付け方に具体的な指針がある。
普通の名詞に形容詞を付けて、変種を示し分ける。
Page Controller と Front Controller がその形。
名前が語彙になる
名前を付ける目的は、技術をまたいで議論できるようにすること。
例が分かりやすい。 Java の listener と .NET の delegate が、どちらも Observer の実装だと分かると、 両方の理解が深まる。
言語やプラットフォームの違いの下に、同じ設計上の考えがあることが見える。
これは結合の度合いで 「ここは位置の連鎖で、次数が高く、局所性が悪い」と言えるようになるのと同じ効き方。 名前があると、指摘が具体的になる。
命名の話とも地続きで、 語彙を持つこと自体が設計の道具になる。
発明ではなく発見
パターンは現場から知識を捉えるものであって、独自のアイデアを提示するものではない。
Fowler 自身の例では、無関係な2つのプロジェクトが根本的に似た方法を採っていることに 気づくまでに数ヶ月かかり、そこから1つの概念として抽象した。
ここから読み手側の含みが出る。 新しさを期待して読むものではない。 熟練した開発者にとって内容が既知なのは正常で、 パターンの役割は、その知識を経験の浅い人へ伝える手段になること。
誤用への注意
書き手への警告として挙がっているものが、読み手の警戒点にもなる。
- 道具のカタログになる危険。 開発者が実際に直面している問題ではなく、 道具の一覧になってしまう。問題の記述が薄いカタログはこれを疑う
- 過度の一般化。 書き手の専門を超えて広げない。 「データベースには詳しいがネットワークには詳しくない人が書くなら、 データベースの状況を記述すべき」。一般化は読み手の経験から来るもの
- 構造の完璧主義。 すべての見出しを埋めようとしない。 弱いプレースホルダを置くくらいなら、省くほうがよい
- 体系への期待。 構造が立派で中身の弱いパターン言語より、 雑然としていても良いパターンの束のほうが価値がある
このリポジトリでの位置づけ
パターンを増やす方向には使わない。
できるだけシンプルと、 結合の度合いの **「すべてを弱くしようとしない。無理に弱めると間接層だけが増える」**は同じことを言っていて、 パターンの適用も、間接層を増やす行為になりうる。
使いどころは2つに絞れる。
語彙として 設計やレビューの議論を、名前で短く正確にする
判断として 「いつ使わないか」を先に考えて、適用しない理由を探す
車輪の再発明はしないの裏返しで、 既にある解に名前が付いているなら、それを使う。 ただし名前を使うことと、構造を導入することは別で、前者だけ取るのは自由。