パターンの次世代
ソフトウェアのパターンを巡る運動に、変化の兆しがあるようだ。
Gang-of-Fourが『デザインパターン』を書き上げてから、10年が経つ。この本から始まり、これまでいくつもの書籍が、ソフトウェア開発の一側面に隠されているパターンをカタログ化し、パターン言語の体系を構築しようと試みてきた。たとえば、以下の書籍がそうした流れの中に位置づけられる。
・『Pattern Languages of Program Design』シリーズ
・F. Buschmannらの『Pattern-Oriented Software Architecture』
・M. Stalらの『Pattern-Oriented Software Architecture, Volume 2』
・M. Fowlerの『アナリシスパターン』
・M. Fowlerの『リファクタリング』
・M. Fowlerらの『エンタープライズアプリケーションアーキテクチャパターン』
・K. Beckの『Smalltalkベストプラクティスパターン』
・D. Alurらの『J2EEパターン』
これらの書籍が扱うソフトウェア開発上の段階はさまざまである。デザインパターンは設計段階のパターンを対象とするものであるが、分析の段階を対象とするものもある。またプログラミングの段階のパターン、いわゆるイディオムと呼ばれるものもあるし、ソフトウェア全体を俯瞰するアーキテクチャのパターンもある。
しかし、共通しているのは、対象とする段階において埋もれていたパターンを、なんとかして名づけ、記録しようという意志が貫かれていることである。どの書籍も、対象のパターンを体系化したい、という動機によって書かれている。パターンの書物を書くことが、非常に尊重されている。
こうした「古典的な」パターン書籍に対し、最近、とくに2000年以降、少し別のスタンスで書かれたパターン書籍に出会うようになってきた。私が上記とは違う感覚を覚えているパターン書籍は、たとえば以下のものだ。
・G. Hohpeらの『Enterprise Integration Patterns』
・E. Evansの『Domain-Driven Design』
前者は、複数の業務アプリケーションをメッセージングを通して統合する際に使われるパターンを説明したものであり、後者は、業務領域を分析して得られるドメインモデルと呼ばれるオブジェクト設計を元に、業務アプリケーションの中核となるビジネスロジックをどうやって設計／実装していくか、についてのノウハウをパターン化したものである。
書籍の中身じたいには、「古典的な」パターン書籍とくらべて何か違うものがあるとことさらに指摘できるようなものはない。違いを感じるのは、書籍が書かれる過程でのパターンと書籍との関係である。
『Enterprise Integration Patterns』の著者Hohpeはインタビューの中で、書きたかったのはエンタープライズインテグレーションであってパターンではなかった、と言い切っている。パターン形式が選ばれたのは、たんにパターンがもつ読みやすさ、参照のしやすさの性質が好まれたからなのだ。同様に、Evansも『Domain-Driven Design』の中で、最初はとくに形式をもたずに原稿を書いていたが、レビュアーのアドバイスによってパターン形式で書き直した、と書き残している。
つまり、ここで挙げた2つの書籍はどちらも、パターンを書くために書いたものではなく、著者が言いたいことを上手く伝えるための手段として、書籍の形式としてのパターンが選ばれただけなのだ。
結果的にできあがる書籍は同じようなパターン書籍であったにしても、この両者の執筆スタンスの違いは大きな違いを生み出すと考えられる。
パターンを書籍の一形式として扱う場合、パターンを書く、という行為に対する自制はほとんど効かなくなる。「古典的な」パターンコミュニティにおいては、パターンとは時間の試練によって鍛えられたものであって、決して斬新な発明であってはならないという認識がある。パターンの著者たちは、「実際に三回以上出会ってからでないと、それをパターンとして記述してはならない」というルールをもっている。しかし、パターンを単にコミュニケーションを円滑にするための形式だと捉えてしまうと、こうした厳格な自制は働かなくなっていくだろう。コミュニケーションの手段というエクスキューズによって、よりカジュアルにパターンをでっち上げられるようになる。
（HohpeやEvansが軽い気持ちでパターンを書いたと思っている訳ではない。彼らは長年の経験から、何度も使ってきたノウハウを文書化したはずである。私が指摘したいのは、今後パターンがたんに書籍の一形式になりうる可能性である）
ちなみに、パターンをたんに文書化の一形式として捉えるスタンスじたいは、なにも最近始まったものではない。むしろ、ソフトウェアパターン運動の黎明期からあるものだ（たとえば、OOPSLA'92で発表されたR. Johnsonの論文「Documenting Frameworks Using Patterns」）。最近顕著になってきているのは、このスタンスが、実際に書籍のアプローチとして実践されつつある点である。
パターンを巡る運動は、ここ数年のどこかの時点で、次世代に突入したのではないかと思う。この世代においては、パターンは時の試練に耐えたものではなく、たんに書籍の一形式として選ばれたものである。そこでは、どんな内容の書籍であれパターンの形式で書くことが全的に肯定される。パターン形式の書籍は、読者にとってとても読みやすく、また参照もしやすいからだ。パターン形式は、Hypertextとの親和性が非常に高い点も見逃せない。
私は、こうしたパターンの次世代の流れに対して批判的な気持ちはまったくない。むしろ、非常に歓迎している。フランスの哲学者ジル・ドゥルーズが著書『千のプラトー』で行なった書籍解体の試みが、まったく別の分野で花開いたような感がある。パターンの書物はまるでリゾームのようである。パターン形式は、ポストモダンと呼ばれる現代に見事にマッチしている。
参考文献：
Gang-of-Fourが『デザインパターン』を書き上げてから、10年が経つ。この本から始まり、これまでいくつもの書籍が、ソフトウェア開発の一側面に隠されているパターンをカタログ化し、パターン言語の体系を構築しようと試みてきた。たとえば、以下の書籍がそうした流れの中に位置づけられる。
・『Pattern Languages of Program Design』シリーズ
・F. Buschmannらの『Pattern-Oriented Software Architecture』
・M. Stalらの『Pattern-Oriented Software Architecture, Volume 2』
・M. Fowlerの『アナリシスパターン』
・M. Fowlerの『リファクタリング』
・M. Fowlerらの『エンタープライズアプリケーションアーキテクチャパターン』
・K. Beckの『Smalltalkベストプラクティスパターン』
・D. Alurらの『J2EEパターン』
これらの書籍が扱うソフトウェア開発上の段階はさまざまである。デザインパターンは設計段階のパターンを対象とするものであるが、分析の段階を対象とするものもある。またプログラミングの段階のパターン、いわゆるイディオムと呼ばれるものもあるし、ソフトウェア全体を俯瞰するアーキテクチャのパターンもある。
しかし、共通しているのは、対象とする段階において埋もれていたパターンを、なんとかして名づけ、記録しようという意志が貫かれていることである。どの書籍も、対象のパターンを体系化したい、という動機によって書かれている。パターンの書物を書くことが、非常に尊重されている。
こうした「古典的な」パターン書籍に対し、最近、とくに2000年以降、少し別のスタンスで書かれたパターン書籍に出会うようになってきた。私が上記とは違う感覚を覚えているパターン書籍は、たとえば以下のものだ。
・G. Hohpeらの『Enterprise Integration Patterns』
・E. Evansの『Domain-Driven Design』
前者は、複数の業務アプリケーションをメッセージングを通して統合する際に使われるパターンを説明したものであり、後者は、業務領域を分析して得られるドメインモデルと呼ばれるオブジェクト設計を元に、業務アプリケーションの中核となるビジネスロジックをどうやって設計／実装していくか、についてのノウハウをパターン化したものである。
書籍の中身じたいには、「古典的な」パターン書籍とくらべて何か違うものがあるとことさらに指摘できるようなものはない。違いを感じるのは、書籍が書かれる過程でのパターンと書籍との関係である。
『Enterprise Integration Patterns』の著者Hohpeはインタビューの中で、書きたかったのはエンタープライズインテグレーションであってパターンではなかった、と言い切っている。パターン形式が選ばれたのは、たんにパターンがもつ読みやすさ、参照のしやすさの性質が好まれたからなのだ。同様に、Evansも『Domain-Driven Design』の中で、最初はとくに形式をもたずに原稿を書いていたが、レビュアーのアドバイスによってパターン形式で書き直した、と書き残している。
つまり、ここで挙げた2つの書籍はどちらも、パターンを書くために書いたものではなく、著者が言いたいことを上手く伝えるための手段として、書籍の形式としてのパターンが選ばれただけなのだ。
結果的にできあがる書籍は同じようなパターン書籍であったにしても、この両者の執筆スタンスの違いは大きな違いを生み出すと考えられる。
パターンを書籍の一形式として扱う場合、パターンを書く、という行為に対する自制はほとんど効かなくなる。「古典的な」パターンコミュニティにおいては、パターンとは時間の試練によって鍛えられたものであって、決して斬新な発明であってはならないという認識がある。パターンの著者たちは、「実際に三回以上出会ってからでないと、それをパターンとして記述してはならない」というルールをもっている。しかし、パターンを単にコミュニケーションを円滑にするための形式だと捉えてしまうと、こうした厳格な自制は働かなくなっていくだろう。コミュニケーションの手段というエクスキューズによって、よりカジュアルにパターンをでっち上げられるようになる。
（HohpeやEvansが軽い気持ちでパターンを書いたと思っている訳ではない。彼らは長年の経験から、何度も使ってきたノウハウを文書化したはずである。私が指摘したいのは、今後パターンがたんに書籍の一形式になりうる可能性である）
ちなみに、パターンをたんに文書化の一形式として捉えるスタンスじたいは、なにも最近始まったものではない。むしろ、ソフトウェアパターン運動の黎明期からあるものだ（たとえば、OOPSLA'92で発表されたR. Johnsonの論文「Documenting Frameworks Using Patterns」）。最近顕著になってきているのは、このスタンスが、実際に書籍のアプローチとして実践されつつある点である。
パターンを巡る運動は、ここ数年のどこかの時点で、次世代に突入したのではないかと思う。この世代においては、パターンは時の試練に耐えたものではなく、たんに書籍の一形式として選ばれたものである。そこでは、どんな内容の書籍であれパターンの形式で書くことが全的に肯定される。パターン形式の書籍は、読者にとってとても読みやすく、また参照もしやすいからだ。パターン形式は、Hypertextとの親和性が非常に高い点も見逃せない。
私は、こうしたパターンの次世代の流れに対して批判的な気持ちはまったくない。むしろ、非常に歓迎している。フランスの哲学者ジル・ドゥルーズが著書『千のプラトー』で行なった書籍解体の試みが、まったく別の分野で花開いたような感がある。パターンの書物はまるでリゾームのようである。パターン形式は、ポストモダンと呼ばれる現代に見事にマッチしている。
参考文献：
- F. ブッシュマン, H. ローネルト, M. スタル, R. ムニエ, P. ゾンメルラード, Frank Buschmann, Hans Rohnert, Michael Stal, Regine Meunier, Peter Sommerlad
- ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系
- Michael Stal, Hans Rohnert, Frank Buschmann, Douglas C. Schmidt
- Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects
- マーチン ファウラー, Martin Fowler, 堀内 一, 友野 晶夫, 児玉 公信, 大脇 文雄
- アナリシスパターン―再利用可能なオブジェクトモデル
- マーチン ファウラー, Martin Fowler, 児玉 公信, 平澤 章, 友野 晶夫, 梅沢 真史
- リファクタリング―プログラムの体質改善テクニック
- マーチン・ファウラー, 長瀬 嘉秀, 株式会社 テクノロジックアート
- エンタープライズ アプリケーションアーキテクチャパターン
- ケント ベック, Kent Beck, 梅沢 真史, 皆川 誠, 小黒 直樹, 森島 みどり
- ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集
- Deepak Alur, John Crupi, Dan Malks, 近棟 稔, 吉田 悦万, 小森 美智子, トップスタジオ
- J2EEパターン 第2版
- Gregor Hohpe, Bobby Woolf, Kyle Brown, Conrad F. D Cruz, Martin Fowler, Sean Neville, Michael J. Rettig, Jonathan Simon
- Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
- Martin Fowler, Eric Evans
- Domain-Driven Design: Tackling Complexity in the Heart of Software
- ジル ドゥルーズ, フェリックス ガタリ, Gilles Deleuze, F´elix Guattari, 宇野 邦一, 田中 敏彦, 小沢 秋広
- 千のプラトー―資本主義と分裂症