思考支援：情報中心システムの視点で既存技術を評価 |
普及のめざましいオブジェクト指向技術は、最近のソフトウェア開発の現場では不可欠になった。データと処理（メソッド）のカプセル化、継承による冗長性の排除、メッセージによる処理の進行といった特徴を持つ。機能が把握しやすく、仕様の変更にも強く、再利用のしやすいソフトウェアを作れる。これらのメリットは、ツールを使うだけでは得られず、オブジェクト指向の理念と活用術を理解している必要がある。
このようにメジャーになったオブジェクト指向技術だが、実は大きく２種類に分けられる。簡単に表現するなら、開発者のためのオブジェクト指向と、ユーザーのためのオブジェクト指向だ。別な言い方をするなら、どのように作るか（作成技術：How）のオブジェクト指向と、何を作るか（作成内容：What）のオブジェクト指向である。現在普及しつつあるオブジェクト指向のほとんどは、前者に含まれる。
開発者のためのオブジェクト指向は、開発ツールとオブジェクト指向OSに分けられる。開発ツールのほうが普及していて、豊富なクラス・ライブラリを持つ開発環境がいくつも存在する。クラス・ライブラリを用意することで、OSがオブジェクト指向でなくても、オブジェクト指向の技術が利用できるため、比較的早く普及し始めた。今日では、単なるコンパイラだと誰にも相手にされないほどだ。データベースとセットになった開発ツールでも、オブジェクト指向の技術を取り込むタイプが増えている。開発ツールがオブジェクト指向の技術を取り入れやすかったのは、過去との互換性をある程度捨て、独立して作れるからである。
それに比べてOSは、内部も含めてオブジェクト指向へ移行するのは簡単でない。OSの持つ全部の機能と内部構造をオブジェクト指向の考え方に沿って構築し直し、それに合わせたクラス・ライブラリを提供する必要がある。すでに動いているOSでは、アプリケーションとの互換性を維持する必要があり、変更は簡単ではない。苦肉の策として、オブジェクト指向に近い形へと変換したインターフェースを用意し、互換性を保ちながらオブジェクト指向OSに近づいている。効率は多少落ちるものの、ユーザーには直接関係ない部分なので、これでも構わない。互換性を維持することのほうが重要だからだ。
OSのオブジェクト指向化は、アプリケーションとのインターフェースや内部構造だけではない。後述するような、ユーザー向けのオブジェクト指向の機能を組み込まないと、本格的なオブジェクト指向OSとは言えない。こちらのほうが重要な機能である。
開発者のためのオブジェクト指向に比べ、まったく進んでいないのがユーザーのためのオブジェクト指向。既存の書類ファイルの単位でなく、もっと小さな部品単位で、データを扱える環境を実現する。アプリケーションよりも小さな部品ソフトを用い、異なるタイプのデータを自由に組み合わせて使える。世の中に出たものの中ではOpenDocが有名だ。残念ながら成功した例はない。
ユーザーのためのオブジェクト指向では、部品を自由に組み合わせる機能だけでは不十分。それ以外に、２つの重要な機能を用意しなければ、使いやすい環境には仕上がらない。最初の１つは、部品であるデータを管理するための機能だ。すべてのデータを部品として作ると、現在のファイルの数と比べて、データの数は何十倍にも何百倍にも増える。これを上手に管理できなければ、ユーザーが混乱する。データベースを利用したデータ管理機能は必須である。単なる分類だけでなく、オブジェクトの関連までも把握できる機能が必要だ。
もう１つの重要な機能は、ユーザーインターフェースの標準化。複数の部品を組み合わせると、何を操作しているのか分かりづらい。表オブジェクトのセル中に、計算式、ムービーなどのオブジェクトを入れた場合を考えてみよう。セルの中身を操作するのか、セルを操作するのか、現在の状況を素早く見分けられるとともに、簡単に切り替える必要がある。それぞれが別なソフトなので、操作方法や切り替え方法を規定しないと、使いやすくはならない。部品のタイプによっていろいろな状況が考えられるので、かなり深く分析してユーザーインターフェースを標準化する必要がある。また、それに沿って、ソフトウェアのインターフェースも用意しなければならない。
以上の２点は、ユーザーのためのオブジェクト指向にとって不可欠な要素だ。ところが、OpenDocは２つとも備えてなかった。とくに、ユーザーインターフェースの標準化が十分に考慮されなかった点は致命的といえる。実際に試して使いづらいと感じるのは、そのためである。必要な条件を満たしていないので、成功するのは難しい。
情報中心システムでも、２つの部分で、オブジェクト指向の技術を利用する。最初の１つは、オブジェクト指向技術を取り入れた開発ツールだ。既存の開発環境と同じように、OSが提供する機能をクラス・ライブラリとして提供し、それを利用しながらソフトを作る。情報中心システムの内部構造は、部品となるソフトを組み合わせて動く形式なので、開発するソフトは小さなものがほとんど。そのため、OSとソフトとのインターフェースをオブジェクト指向で設計する必要性はそれほど大きくない。グラフィックなどの一部の機能だけで採用すればよい。
残りの１つが、情報中心システムらしい利用方法。項目を集めた構造体定義の機能で、継承による階層的な定義をサポートする。「動物」構造体のサブクラスとして、「犬」構造体を定義するという具合に使用する。メソッドに相当するのが処理定義だ。ただし、情報中心システムでは、使用する処理定義をユーザーが実行時に変更できる。また、同じデータに複数の処理定義を実行し、その結果を比べるといった使い方も受け付ける。このため、通常のオブジェクト指向とは異なり、別な属性や機能を追加する。
構造体定義や処理定義は、ユーザーによる追加や変更が可能である。その意味から、ユーザーのためのオブジェクト指向を実現した１つの形とも言える。OpenDocとは異なる形であって、格段にレベルの高い。少し困るのは、継承の考え方が一般ユーザーに理解しづらい点だ。使いやすくするためには、構造体定義の作成機能で、階層や継承を見やすく作る必要がある。
定義機能にオブジェクト指向の考え方を取り入れるだけでは、使いやすいシステムには仕上がらない。Object First機能を利用したユーザーとのやり取り、データや処理を把握する機能、分かりやすい表現内容を自動生成するAuto Expression機能、好みの抽出条件や表現方法を登録する表現フレームなど、情報の特性を重視しした機能があって、使いやすい情報環境を実現する。
（1997年４月27日）
オブジェクト指向：開発者向けでは成功 |
