あるオブジェクトの集まりがどのように振る舞えばよいかを記述した、別のオブジェクトの集まり (メタ・レベル(meta level)とも言う)
<<図>>
知識レベル(Knowledge Level)(42)は、抽象的なパターンの一つで、それがどんなものであるかを記述するのは大変難しい。とは言っても、少しでも複雑なオブジェクトの系ではしばしば見い出されるものである。知識レベル(Knowledge Level)(42)が現れるのは、あるオブジェクトの集まりのインスタンスが、操作オブジェクトの集まりの振る舞いに影響を与える場合である。こういった知識オブジェクトを生成し、つなぎ合わせることによって、システムを「プログラミング無しで」変更できるようにするのが典型的な例である。
<<図0.21 従業員(employee)を用いた知識レベルの例>>
図0.21は従業員(employee)に関する知識レベルを用いた例である。ここで意図しているのは、報酬と退職のポリシーを一つに組み合わせることによって、従業員の型というものを作り出すことである。こうすると、各従業員はどのポリシーを採用するかを示す従業員型で印付けられることになる。従業員の就業形態をカスタマイズする必要が出てきたら、報酬体系と退職計画の別のインスタンスをもつ、新しい従業員型(Employee Type)のインスタンスを生成すればよい。これらのオブジェクトの選択と結合が、システムの構成を決めていることになる。
この本では、前の版と同様、知識レベル(Knowledge Level)(42)という用語を使う。とはいうものの、設計者の仲間うちでこれがまったく標準的な用語として使われていると主張するつもりはない。まだ今のところ標準的な用語といえるようなものは存在していないので、私は取りあえず知識レベル(knowledge level)という用語にこだわろうと思う。
私は英国国営保健サービスのCosmosプロジェクトで働いているときに、操作レベル(operational level)、知識レベル(knowledge level)という用語を使い始めた。このプロジェクトで、私は医師と看護婦の合同チームについて仕事をしていたのである。我々がその用語をひねり出したのは、そのときのモデルの見え方にまさにぴったりしていたからなのだ。操作レベルでのオブジェクトは医療者の日々の操作的な振る舞いを表していたし、知識レベルのオブジェクトは彼らの医療上の知識を表していた。
一般的によく使われる別の用語としては、「メタ・データ(meta-data)」のメタ(meta)のような言い方がある。メタとは「〜について」という意味のギリシャ語なので、メタ・データとは「データについてのデータ」ということになる。「メタ・オブジェクト」や「メタ・レベル」について喋っている連中をよく見かけるだろう。もしこの概念を表す用語の投票をすることになったら、「メタ何とか」は多分リストのトップになるに違いない。しかしそれでも私としては「知識レベル」を推したい。ソフトウェア関係以外の人にも意味が通じると思うからだ。
別の言い方としては「アクティブ・オブジェクト・モデル(Active Object Model)」がある。この言い方の根拠は、知識オブジェクトが操作オブジェクトの振る舞いを決定するアクティブな部分を司っていることからだ。しかしこの用語は広く使われているわけではないし、操作レベルが何か受動的なもののように取られてしまうのであまり好みではない。
私の個人的な習慣としては、図の上側に知識レベルを、下側に操作レベルを書き、その間を点線で区切る(そうしない場合もある)。これもまた、私がこれが役立つものだと分かったときに関わっていたCosmosプロジェクトでの習慣である。しかしこれはどんな標準にも含まれていないし、私の世界への影響力など、私が期待するほどのものでないのは確かだ!
知識レベルと操作レベルの間を「何とか」と「何とか型」という関連で結合するのは、一般 的な慣習である。これは非常によく使われるようになってきたので、私も他の名前の付け方を提唱するのをためらってしまう。型オブジェクト(type object)パターンに従って、「何とか型」を「何とか」の型オブジェクト(type object)と言うこともある。
知識レベルは全体的に考えるには大変込み入ったものであり、普通の人はこれを先進的なオブジェクト指向テクニックだと見なすだろう。難しい点は、ソースコードをほとんど(あるいはまったく)変えずに変更を扱えるようにするためのオブジェクトの集合を選び出すところにある。どの組み合わせならばうまく動作するかをあらかじめ見極めるのはたいがい難しい。 そして、もっとも複雑なフレームワークと同様、設計は進化し続けなければならない。
これをどうやってやるのかを抽象的に述べることはできない。その代わりに、知識レベルを含むような個々のパターンをよく見て、そこから何か使えそうな事柄を学び取ろう。そうすれば、あなたも特定のパターンを使うことができるようになるはずだ。また、知識レベルをよく見ることで、あなた自身の環境に対する知識レベルがあなたを助けてくれることもあるだろう。
人が知識レベルを使いはじめる、あるいは使おうとし始める。そのときよくあるのは、これでプログラマでない人が「プログラミング無しで」システムの挙動を変更できるようになるだろうと考える場合だ。こういうのはしょっちゅうあることなのだが、私の経験ではこれは「幻の黄金郷」に過ぎない。知識がどのように働くか、知識をどのように構成するかを理解することはまだまだ非常に込み入った課題であって、普通 のプログラマの手には余るようなことなのである。実際、経験豊富なプログラマでさえ、知識レベルを扱うのが非常に難しいと実感することも多い。
私の考えでは、知識レベルの利点は設計の経験を積んだ人が、他の方法でやるよりはすばやく変更をできるようになることである。
これらの変更の多くを実行時に行うことができるという事実も、また魅力であろう。しかしこれには警告を伴う。つまりシステムを「プログラミング無しで」変更できるからと言って、システムをテスト無しで変更していいと言うことにはならないからだ。実際、知識レベルに対するテストはより重要になり、しかもたいていはテストをするのが難しくなる。知識レベルはそもそも大変動的なものを捕らえるためのものであり、だからこそテストも大変難しい課題になるのである。
「プログラミング無しで」変更できると言うことはまた、変更をツールを使わずに行わなければならないということでもある。知識レベルだからといってデバッグが不要になるわけでも、構成管理が不要になるわけでもない。あなたの「プログラミング不要」環境がデバッグ、構成管理、テストのためのツールを用意していない(し、これからも用意するつもりがない)ならば、あなたはそれらの道具無しでやるか、自分で作るしかないのである。知識レベルのためのグラフィカル・エディタを作る人々がよくいるが、実際には「プログラミング不要」のいちばん難しい部分は編集以外の部分であるのが普通だ。
これらのことはすべて、知識レベルを利用する上での重要な警告になるが、もしこれらのことであなたがおびえてしまうようならば、ここは考えどころである。これは軽く使うようなパターンではない。しかし、複雑なビジネス・システムでは知識レベルがそのコストに見合うようなポイントもいくつかはあるものである。例えば一定しないルールが大量 にあるような場合には、知識レベルは大いに意味があるだろう。我々は実際のところ、これらを使うにあたってのガイドラインがどんなものであるかということについて、まだあまり言うべきことを持ち合わせていない。しかし、これらはめったに使われることはないが、本当に必要な場合にはそれが本質的な役割を果 たすということは分かっている。ちょうどパラシュートみたいにね。