2． 2つの基本概念

2．2 フレームワーク

フレームワークは、アーキテクチャにくらべ、実際の具体物が存在するという点で、より明確にとらえることができます。通常は、「特定のアーキテクチャに基づき、実装された半完成のシステム」を指します。「アーキテクチャの実例」といってもいいでしょう。

プレハブ住宅の建築法で、「ユニット工法」というのがあります。これは壁、床、天井、設備などをあらかじめ組み上げたユニットを作っておき、ユニットを全体の枠組みの中で相互に結び付けることで、家を作ってしまうといったものです。従来の、まず土台を用意し、柱と梁で支えと作って、筋交いで強度を高め、というやり方に比べ非常に短期間で作成でき、品質が大工さん個人の職人的技量に左右されないというメリットがあります。

フレームワークは、この「ユニット工法」の考えと非常に似ています。

アーキテクチャに基づいてソフトウェアを作るといっても、一からすべてを構築していったのでは非常に大変です。そこで、特定のアーキテクチャに基づいて実装されたできあいの半完成システムに対し、プラグインとして作成した(もしくはどこからか入手した)特定のソフトウェア部品をはめ込むことで、望みのシステムを手速く、安定したものとして作れるようにするのです。

フレームワークの代表例としては、古くは、柔軟なGUIを簡単に構築するMVCライブラリ、最近では、DBに接続するロジック層の構築を容易にするEJB(Enterprise Java Beans)、IBM SanFranciscoなどがあります。Appletの仕組みもまた、Thin-Clientを実現するための一種のフレームワークといえます。開発者はAppletのサブクラスを作成(もしくは入手)するだけで、WWWブラウザを通じ、サーバから動的にAppletを受け取ってクライアントとして実行させていくことが可能になります。

フレームワーク開発者側では、なんらかのプラグを用意しておき、プラグイン開発側は、そのプラグにうまくはまり込むような、カスタム部品を作成することになります。オブジェクト指向によるフレームワークの場合は、通常、フレームワークで提供する抽象クラスをサブクラス化したクラスを作り、はめ込むことになります。

フレームワークの概念図

メインの流れはあくまでフレームワークが支配しています。この流れからプラグインが呼び出され、処理が進んでいきます。こうしたことで全体を制御しつつ柔軟なカスタマイズ性を実現するのです。

また、フレームワークで大事なのは、どの部分をプラグインできるようにし、どの部分を出来合いのものとして固定化するかということです。この選択を間違えると、手の込んだだけの使えないフレームワークになってしまいますので注意が必要です。

メタパターン(フレームワークを構成するためのデザインパターン)を定義したWolfgang Preeは、フローズンスポットとホットスポットという言葉で、このことを表現しています。フレームワークを作成する際に、ドメイン分析の結果、固定化しており、今後の変更が起こらないと思われる部分は、強固な流れを規定するフローズンスポットとなり、一方で新たな要求の発生が予想され、その変更に対し柔軟に対処できるようプラグを用意した部分がホットスポットとなります。

フローズンスポットとホットスポットの図

どの部分がフローズンスポットであり、どの部分がホットスポットであるかの区別は自動的にできるものではありません。この分割を行っていくには、開発者側の都合を考えただけではだめで、ユーザから得るアプリケーションのドメインに関する知識が不可欠です。ユーザの要求の中で変化しやすい部分とそうでない部分を見定めて「分けていく」作業は、まさに「分析」作業ということなのです。
ただし変化しやすい部分をホットスポットとして、実装コードの中に適切に表現していくには、単にこの切り分けができているだけでは不十分です。実際にフローズンスポット、ホットスポットをコードとして組み上げていくには、そのための道具といったものが必要です。

そこで、登場するのがデザインパターンということになります。

デザインパターンの説明に入る前に、今までの話の具体的なイメージをつかむため、Squeakを題材にMVCアーキテクチャ、更にそのフレームワークとしての実装を見てみましょう。

Prev.

Index