～プログラミングって面白そうと思った方に向けた連載エッセイ～

　プログラミングの世界に、デザインパターンと呼ばれるものがある。

　類型化されたプログラム上の問題に対し、解決策としてあるパターンが提示され、名前をつけられる。その効果が広く認められれば、汎用的なツールとして世界的に流通するようになる。「○○パターンで」と言えば、技術者間では「はいはい」となるくらい常識化しているパターンもいくつかある。

　もともとは建築のデザインパターンになぞらえて命名された。実用に資するという共通点から、概念的に参考にできる点が多くあったのだろう。建築家クリストファー・アレグザンダーの提唱した「パタン・ランゲージ」から多くの影響を受けているという。

　パターンとは模倣であり、省力化である。それは、あちらこちらで起こる問題の解決にかかる労力の省力化であるとともに、伝える労力の省力化でもある。プログラムがあるパターンに基づいて実装されていれば、どのような問題に対して何を意図してどのような構造で実装されたのか、おおよその見当がつき、理解の助けになる。

　デザインパターンは一般に美しいものと認識されている。美しくないパターンはそもそも流通しないので、よく目にするパターンが秀逸だということもあるだろう。が、それだけではない。パターンを使う、標準に倣うことがプログラミングの世界では美しいとされている。拠るべき標準は、できるだけ広く、多くの人に浸透しているものが望ましい。ローカルな標準は、いつグローバルな標準に駆逐されるかわからない、想定ケースが甘くなりがち、という二つの意味で脆い。その維持にはコストもかかる。

　標準は規格化されていることもあれば、デファクトスタンダード（事実上の業界標準）やベストプラクティス（最善の慣行）として広く認知されていることもある。デザインパターンに関しては、"GoF"("The Gang Of Four") （エーリヒ・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディースからなる「４人の奴ら」¹）によって定義されたものが圧倒的に有名で、実際に使用される機会も多い。

　建築や美術、音楽の世界では、ある種の作品が「様式美」と評されることがある。形式的に限定された、ルールを与えられた中での表現とその鑑賞に、特有の趣があるのだろう。プログラミングのデザインパターンは様式美とは少し異なる。むしろ対照的なものかもしれない。○○風の流れに乗る、といった趣味的要素はそこにはない。デザインパターンを支えるのは必然性である。優秀な技術者が考え抜けばいつか辿り着くであろう共通の解決策を整理したもの、という見方もできる。そこには根拠があり、目的がある。パターン自体は手段にすぎない。様式美は意図的な形式的模倣と考えられるが、デザインパターンの活用で重視されるのは形式ではなく、問題の実質的解決である。

　パターンを使うことで、達人たちが試行の末にたどり着いた知恵に労せずしてあやかることができる。適切に利用される限り、パターンをなぞることが「パクリ」と非難されることはない。プログラムは「言語」である。言語は模倣を前提に成り立っている。プログラミングにおいて、模倣それ自体は悪ではなく、むしろポジティブに評価されることが多い。

　ただし、デザインパターンを言い訳や盾に使ってはならない。パターンは、それを使うだけでいいコードになるという魔法ではない。無条件に品質を保証したり、レビューアから守ってくれるわけではないし、知っているパターンの数がプログラマの質に直結するわけでもない。

　コードの置かれた状況は似ているようでも個々に異なる。それを見極め、ここぞというときに活用してこその知恵である。流通しているパターンにそれなりの信頼性と効用があるのは間違いないが、神格化するのでなく、ここで使うとどんなありがたさが待っているのか、トレードオフも踏まえて意識できるとよいだろう。

　とは言うものの、パターンを覚えたての時期はつい濫用しがちになる。それは一つの「アンチパターン」ではあるが、覚えたら使いたくなるのがプログラマの性、向上心の証とも言えるだろう。多少はご愛敬、ただし効果の検証は怠らず、違ったなと思ったらリファクタリングを検討しよう。

序章
 第一章　その美の特徴
 第二章　見た目と冗長性
 第三章　ロジック
 第四章　命名
 第五章　アーキテクチャ
 第六章　リファクタリング
第七章　デザインパターン
第八章　正規化
 終章

私訳。「四人組」「４人のギャングたち」と訳されることが多いが、英語圏の方に確認したところ、冗談っぽい使い方ということだったので。 ↩