オブジェクト指向プログラムのためのパターンランゲージの使用

以下の文章は、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のウィンドウを設計するためのごく小さなパターンランゲージについて考えてみよう。我々は以下のパターンを提案する。

  1. タスクごとのウィンドウ（Window Per Task）
  2. ウィンドウに対してペインはできるだけ少なく（Few Panes Per Window）
  3. 標準ペイン（Standard Panes）
  4. 短いメニュー（Short Menus）
  5. 名詞と動詞(Nouns and Verbs)

我々は、これらのパターンをある特別な目的のためのプログラミング環境用の仕様書を書いているアプリケーションスペシャリストチームに提供した。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個になると予測している。ユーザーインターフェイス設計におけるパターンランゲージの使用が最初に成功したときは、コンピュータユーザーたちが自分自身のアプリケーションを自らが設計し、プログラミングするという可能性があるのだということに、我々は大変熱狂した。

参考文献

日本語訳について