以下の文章は、Kent Beck、Ward Cunninghamによる「Using Pattern Languages for Object-Oriented Programs」の日本語訳である。
Ward Cunningham氏の許可を得て、ここに掲載する。
Kent Beck, Apple Computer, Inc.
Ward Cunningham, Tektronix, Inc.
概要
オブジェクト指向プログラミングへのパターン言語の適合について概説する。ウィンドウ・ベースのユーザ・インタフェース設計時にうまくいった5つのパターン・システムについてまとめた後、あるパターンについてもう少し詳細に述べる。これは、オブジェクト指向プログラムの完全なパターン言語を記録する我々の現在の活動から得られたものだ。
オブジェクト指向プログラミングのための適切な方法論の探索は、これまで古臭い考えを焼き直したものに過ぎなかった。OOPは従来の考え方とは全く異なっており、従来の構造化分析やエンティティ・リレーションシップ(E-R)の手法をそのままあてはめるだけでは、OOP本来の潜在能力を引き出すことはできない。特に気になるのは、どちらの手法も最も重要な設計事項であるユーザ・インタフェースに重きを置いていない点である。E-Rは一見「オブジェクト指向」のように見えるが、Smalltalkに見られるような動的なオブジェクトに適合していないばかりか、オブジェクト指向プログラミングで取り除かれた、設計時におけるグローバルな視点をも推奨している。
我々は、設計や実装の負担について急進的な変革を提案する。ここでは、Christopher Alexander氏（建築家、Environmental Structuresセンターの設立者）の業績をアレンジしたコンセプトを使う。Alexander氏は、家やオフィスというものは、実際にそこにいる人たちの手によって設計され、作られるべきだと提案している。氏がこう結論付けたのは、ある構造（a particular structure）への要求を一番よく知っているのは、彼ら自身だからだ。我々はこれに賛同し、コンピュータ・プログラミングにも同じ論旨を展開した。つまり、コンピュータ・ユーザーは、自分自身のプログラムを書くべきなのである。この考えはアホみたいに聞こえるかもしれない。建築とプログラムとの規模や複雑性の違い、設計のプロになるためのトレーニング年数などを考えると、その通りだろう。しかし、Alexander氏が説得力のあるシナリオを提供している。そのシナリオは、「パターン言語」と呼ばれるコンセプトを中心に展開されている。
パターン言語とは、設計過程で発生するあらゆる問題に対し、実際に機能するソリューションを提供することで、設計者を導くというものだ。パターン言語は、一連のちょっとした知識が、ある一定のスタイルで記述、整列されており、設計者がその時点で最も適した質問を尋ねる（または答える）ことができるようになっている。Alexander氏は、これらの知識を共通した構造を持つパターンとして記述した。各パターンには、問題、問題が発生する状況の概要、そして（最も重要な）その状況下で有効なソリューションが記述されている。パターン言語はそれらのパターンを集めることで、完全なる構造を形成する。例えば、住居やインタラクティブ・コンピュータ・プログラムなどである。パターン言語内では、パターンはお互いにつながっており、そこでは、ある決定が他に影響する。パターンには、このつながりがプロローグとエピローグに記述されている。Alexander氏は、重要ではない言語は相互の影響サイクルがなくとも形成可能である。そのため、設計プロセスは前段階の決定を省みる必要なく進めることができる、と述べている[Alex77]。
それでは、Smalltalkのウィンドウを設計するためのごく小さなパターン言語について考えてみよう。我々は以下のパターンを提案する。
我々はこれらのパターンをある特別な目的のためのプログラミング環境用の仕様書を書いているアプリケーション・スペシャリスト・チームに提供した。Smalltalkのインタフェース・メカニズム（MVCなど）の詳しい理解がなくとも、1日ほどプラクティスを行っただけで、彼らはよくできたインタフェースを記述することができた[Cunn87]。我々がパターンに番号をつけ、順番に並べていることに注意して欲しい。パターン1がまず最初に来なければならない。これは、どのウィンドウが利用可能であり、そこで何が行われるかを決定している。次のパターン2と3は、各ウィンドウをペインに分けている。最後のパターン4と5は、各ペインの中の選択やアクションが何をやるかということを決めている。この順番は、各パターン間の影響度の相対値により決められた。我々はオブジェクト指向プログラミングの完全なパターン言語を記述し始めたばかりだ。例えば、「Collect Low-level Protocol」（ロー・レベル・プロトコルの収集）と呼ばれるパターンがある。以下にその要約を掲載する。
最初にシステムをオブジェクト[Objects from the User's World] （ユーザーの世界からのオブジェクト）に分解し、オブジェクトを洗練すると[Engines and Holders] （エンジンとホルダー）、どのオブジェクトにもフィットしない便利な関数を集め始める必要がでてくる。オブジェクトの多くは、ロー・レベル（ビットやバイトの世界）でコミュニケートする必要がよくある。 例えば、外部ファイルは複雑なフォーマットや高度にエンコードされたフォーマットとなっており、その解釈には相当量のバイト（さらにはビット）操作を必要とする。
ファイル・フォーマットをデコードするために必要なすべてのプロトコルや、その他、ある目的のためだけに設計されたオブジェクト内のロー・レベル・タスクを集めよ。様々なオブジェクトに散りばめられていたとしても、集めるのだ。これをやりさえすれば、オブジェクトをテストしたり、洗練したりすることができる準備が整うのだ[Elegance through Debugging]（デバッグしてエレガントに）。
我々はおよそ10個のパターンを完成させた。スケッチだと、20から30個を超える。パターンを完成させる頃には、100から150個になると予測している。ユーザー・インタフェース設計におけるパターン言語の使用が最初に成功したときは、コンピュータ・ユーザーたちが自分自身のアプリケーションを自らが設計し、プログラミングするという可能性があるのだということに、我々は大変熱狂した。
訳：kdmsnr
キーワード:
参照: