« 「ユース・ファースト」なシステム開発 | トップページ | ツール開発には変人が必要である »

2009.01.13

フレームワークはオブジェクト指向を隠蔽する

 「CONCEPWARE/販売管理」の実装版といっしょに実装用のフレームワークも開発しているのだが、その過程でオブジェクト指向の威力にあらためて感じ入っている。適切なクラスを導入することでソフトウエアの内部構造がエレガントになる。アルゴリズムを考えるのも楽しいが、クラス構造を考えることにも独特な楽しさがあって、歩きながら考え込んでコケそうになるくらいだ。実装用フレームワークのような複雑なソフトウエアを組み立てる際に、オブジェクト指向は欠かせない。

 オブジェクト指向を駆使しつつプログラミングしていて、フレームワークがオブジェクト指向を「隠蔽」するという逆説的な方向性を持っていることに気づいた。

 筆者が開発しているフレームワークは、生産管理システムや販売管理システムといった企業向け基幹システム、いわゆる「業務システム」向けのものだ。したがって、フレームワーク内部のクラス構造は、「業務システムにおいて利用されるソフトウエア」を抽象化したものとなる。ユーザーのログイン、ユーザの権限に応じたメニューの表示、メニューオプションにもとづく機能の起動やスタック管理、機能の利用履歴の記録、そういった標準的なふるまいをフレームワークが肩代わりすることになる。

 「業務システム」をはじめとしたさまざまなドメイン(ソフトウエアの適用領域)向けに用意された実装用フレームワークがいろいろあるとする(図1の緑色の要素)。それを用いることで各ドメイン向けのソフトウエア作りが容易になる。必要とされているソフトウエアのふるまいに応じたクラス構造が、あらかじめフレームワークによって確保されているからだ。フレームワークの利用者(つまり個々案件の開発者)はあらためてクラス構造を悩む必要がなく、ドメイン・スペシフィックな問題に集中しながらソフトウエアを組み立てていける。フレームワークが、プログラミング言語とドメインとの世界観の違いを吸収する翻訳装置になっているということだ。

Image090111_1

 なお、「クラス構造を悩む必要がない」と書いたが、それは「クラス構造を考えることが楽になる」どころではなく、極端にいえば「クラス構造なんて観念さえ知らなくていい」という意味であり得る。議論の様相を、個々の言語ではなく個々のドメインのほうから見ると事情がわかる。

Image090111_2

 特定のドメイン(たとえば「業務システム」)に対して、さまざまな言語(オブジェクト指向の言語Aや言語B、ホゲホゲ指向の言語C等)で作られたフレームワークがいろいろ用意されているとする(図2)。個々案件の開発者は、フレームワークを利用する過程で、プログラミング言語レベルの諸問題(オブジェクト指向やホゲホゲ指向等)を意識する必要が(本来ならば)ない。フレームワークが、その利用者に対してそれらを隠蔽するからだ。

 営利行為として特定ドメイン向けのソフトウエアを開発するのであれば、プログラミング言語でスクラッチコーディングすることはせず、なんらかの実装用フレームワークを用いて合理化をはかるものだ。結果的に、個々の案件を担当する開発者はオブジェクト指向等の「プログラミング言語特性」を必要以上に知らなくてよいということになる。開発者をドメイン固有の問題に集中させることがフレームワークの役割だからだ。言い換えれば、フレームワークを利用しつつ個々の開発案件を扱う開発者が実装上の諸問題を強く意識しなければならないとしたら、それはフレームワークから実装上の特性がドメインに対して「漏れ出している」ということであって、フレームワークとして成熟しているとはいえない。

 オブジェクト指向言語のように強力なプログラミング言語を用いることで、フレームワークの内部に自身の特性(オブジェクト指向)を隠蔽することは容易なのである。プログラミング言語の可能性やプログラミングの面白さ、そういうことをあらためて思わされる。

|

« 「ユース・ファースト」なシステム開発 | トップページ | ツール開発には変人が必要である »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: フレームワークはオブジェクト指向を隠蔽する:

« 「ユース・ファースト」なシステム開発 | トップページ | ツール開発には変人が必要である »