オフジェクト指向 への招待 Sma 翡 ta 80 とオフジェクト指向 前回は , オプジェクト指向の観点から , C 第 5 回 Sm 訓 ta 賑ー 80 を例に取り上けてみたい。 十十について解説したわけだか , 今回は , Smalltalk-80 を 巡る状況 オプジェクト指向について解説する場八 ロ , Sma Ⅱ talk ー 80 について触れないわけにはい かないだろう。私たち C 言語のエンジニア は , この SmalItaIk-80 をどのように捉えた らよいのて、あろうか ? 多くのオプジェクト指向に関する解説記 事や論文て、 , Smalltalk-80 はオプジェクト 指向型言語の究極の姿として捉えられてい る。一般論としていえば , それはまちがい ない事実て、あろうが , それては , 実際に C 言 語を用いてプログラミングを行っているフ ィールドて、は , どうて、あろうか ? オプジェクト指向は , 90 年代のプログラ ミングにおいては , 避けて通ることのて、き ない技術て、あるといわれる。とすれば , は たして C 言語が FORTRAN やアセンプリ言 語の領域に入り込んて、きたように ,Smalltalk ー 80 が理想のオプジェクト指向型言語として 私たちの前に現れてくるのてあろうか ? 今 76 CMAGAZINE 1991 2 木戸研一 後 , 私たちは Smalltalk ー 80 を用いてプログ ラミングしていかなくてはならないのて、あ ろうか ? どのオプジェクト指向の解説書て、も , オ プジェクト指向の優位性や Smalltalk ー 80 の ューザインタフェイスやツールの使いよさ について述べるばかりて、 , 実際のプログラ ミング作業の将来と , オプジェクト指向の 関わりあいについては , 直接的な言及がな されていないようて、ある。そこて、 , 今回は , ほかのオプジェクト指向の解説とは若干観 点を変え , Smalltalk ー 80 に関するこうした 占を中心に考えていきたい 最近て、は , SmalltaIk-80 もかなり一般化 してきた。ほんの数年前まて、は , オプジェ クト指向もふくめ , 解説書はわずかしかな かったし , 実際に動くシステムも , 富士ゼ ロックス社かソニーテクトロニクス社の高 価な専用ワークステーションに限られてい たため , ほとんどが研究目的て、あって , 実 際に開発現場て、目にすることはなかった。 筆者が SmaIItalk-80 に触れはじめた 1985 年頃は , Smalltalk ー 80 のユーザを「選ばれ た 1000 人」と呼んて、いたような記憶がある 1000 という数字の根拠はさだかて、ないが , 当時の Smalltalk ー 80 のユーザがごくわずて、 あったことを , 比喩的に表現したものて、あ る。 sma Ⅲ alk ー 80 自体がそうした状況て、あ 一般性をもった概念として , オプジェ り , クト指向がプログラミングの世界て、語られ るということもほとんどなかった。唯一 前々回に述べた , 松岡洋氏による , 「 ASCII 』 誌の「プログラミング言語のスタイル」と題 した , 「アドベンチャーゲーム記述」 ーコロロ 「メッセージ伝送とは何か ? 」 , 「オプジェクト 指向型言語の作り方」の一連の記事が , オプ ジェクト指向について , プログラミングと いう現場を想定して簡潔に解説したものて、 あった その後 , オプジェクト指向が注目される ようになり , また Smalltalk -- 80 を巡る状況 にも大きな変化が起きている。最近情報処 理の世界て、ワークステーションが大きなシ ェアを占めるようになってきているが , そ れらにも Smalltalk-80 が登載され , 比較的

指して , プロトタイプと呼ぶことが多いの てある。 Sma Ⅱ talk ー 80 やオプジェクト指向に関す るプログラムの例として , クラス階層やオ Fig. 1 社員名簿のプログラム例 仕様 プジェクトの構造などを示しやすいものが よく取り上げられる。たとえば , 動物と人 間とか , 家具と机とかの階層て、あるが , C 言 語て、 , こうした人間や家具などを直接プロ グラムすることは , よほど特殊なシステム て、ないかぎりまずないだろう。そこて、 , 簡 単な社員名簿について考えてみる。 ソフトハウス A 社には , 技術系と , スタッ 社員名簿 どういうものか ? キーで参照できるか NO Bag Yes 要素重複を許すか No No Set Yes ArrayedCoIIection 要素の種類 任意 名簿 RunArray 80 CMAGAZINE 1991 2 CoIIection その要素は順番に 並べられているか Yes SequenceabIeColIection 順序付けの方法 任意 要素の種類 No キーで参照できるか 外部 Array OrderedCoIIection

COMPUTER LANGUAGE ・覊物日ん印物締朝 0 $ / 2 Digest of LANGUAGE November 1990 VOLUME 7 NUMBER 11 FLOCKING TO OS / 2 最近 , MS-Windows の影に MS OS / 2 がす っかり隠れてしまった観があります。昨年 , アメリカて MS-Windows Ver. 3.0 がリリー スされて , 爆発的な売れゆきを示している ようて、す。今春の日本発売がおおいに待ち 望まれるところてす。現状から判断すると , しばらくは MS-Windows が主流をなすのて はないて、しようか。 それに対し , MS OS / 2 の本格的な普及は まだ見えてきません。現在 , ューザが保有 しているマシンの機能て、はまだまだ OS / 2 は 重く , また , 現状て、は MS-DOS と MS-Win dosws て、十分 , というところなのて、しよう か。 OS/2 がなかなか普及しない理由として は , MS OS/2 を本当に必要としているアプ リケーションがまだ少ない ということも 考えられます。 OS / 2 て、なくては , という魅 力的なアプリケーションの登場が待ち望ま れます。 「 Flying Along the Migration Path( 移 行への道に沿って飛翔 ) 」は , MS OS/2 と MS -Windows との間にある隔たりについて , 実 例を用いて解説しています。 MS OS/2 や MS ー Windows の環境下て、のプログラム開発は , 現時点て、は必ずどちらかひとつを選択しな ければいけない状況にあります。ところが , MS OS / 2 の機能をながめてみると , その中 にはいくつかおもしろい機能がサポートさ れています。 たとえば , MS-Windows から MS OS/2 へ 移行させるためにふたつの方法が提供され ています。正確には , 提供される予定にな っています。ひとつは , バイナリレベルて、 の互換性をもたせた BCL(Binary Compati bility Layer) と , もうひとつのソフトウェ ア的にプログラムを移行させるツールキッ ト SMK(Software Migration Kit) て、す。 BCL は , MS OS/2 の中 <MS-Windows を 36 CMAGAZINE 1991 2 実行可能にする API を提供することて、 , MS -Windows のアプリケーションを起動て、きる ようにしたものて、す。この機能は MS OS/ 2 Ver 2.0 から提供される予定になっていま す。 SMK は , MS-Windows 用のプログラム を MS OS/2 用に変換させるプログラムて、 す。しかしながら , この方法て、は再リンク を行わなくてはならず , アイコンの形式も MS OS/2 用に変更しなければいけません。 したがって , 多少不便を感じるきらいはあ りますが , ソースプログラムを変史しなく てもよい点はたいへん便利な機能といえる て、しよう。ただし現時点て、は , この機能の サポート予定時期が明確になっていません。 本稿は SMK のバージョンを使用して MS -Windows から MS OS / 2 へのプログラム移 行の実際を例に説明がなされています。 「 Using CASE for Object ー Oriented Design with C 十十 ( C 十十でオプジェクト指 向型の設計を行うために CASE を使用 ) 」て、 は , C 十十によるオプジェクト指向の設計を サポートする CASE を使用しながら , 設計方 法の主体を説明した記述内容になっていま す。先月号て、も紹介したように , 最近て、は このようなオプジェクト指向型の設計論が 大きなウェイトを占めるようになってきて います。おそらく , この傾向はもう少し続 くと思われます。日本て、も今年はこの種の ツールの出現が予想されます。 本稿は , C 十十によるオプジェクト指向プ ログラミングの実際をより具体的に説明す るために , ERD(Entity ー ReIationship Dia gram), STD(State ー Tradition Diagram), そして DFD(Data-FIow Diagram) が使用さ れています。 ERD はクラス設計を行うために全クラス の関係を示し , STD はクラスのライフサイ クルや動きを示します。 DFD は , 各クラス の状態を示しています。いずれもオプジェ クト指向型設計て、必要と思われるものて、す。 ただし , 記事中てはオプジェクト指向型設 計にとって必要なデータ分析の記述が少な いため , 多少理解しにくいきらいがありま す。最後まて、読み通すには苦痛を感じるほ ど高度な内容といえるて、しよう。 「 Command ー Line Retriver for OS / 2 ( OS / 2 用のコマンドライン検索 ) 」て、は , OS / 2 用のコマンドラインを保存し , それを再利 用したり , 編集したりするための CLR コマ ンドの開発を紹介したものて、す。 C プログラ ムのソースを掲載しており , その説明と使 用方法について十分な解説がされています。 また OS / 2 用の開発て、あるため , OS / 2 の理解 に必要な解説もされています。とくに , キ ーボ、一ドモニタの設計は , このプログラム の基本となるところて、す。同様に , パイプ コマンドの設計や DLL の設計についても触 れられています。 「 What Good is se 旧 ( se げは何がよいか ) 」 て、は , Turbo Pascal Ver. 5.5 て、使用される 引数 self を使用したプライベートメソッドの 構築を実際のパスカルプログラムを用いて 解説しています。もちろん PascaI を理解し ていることが前提となりますが , 実際には Turbo PascaI Ver. 5.5 のオプジェクト機能 を使用した例て、す。 self は , Turbo Pascal Ver. 5.5 の機能のひとって、 , マニュアルによ ればとくに目立った機能を有しているよう には思えません。しかし , 筆者は self 機能を うまく利用することて、プライベートメソッ ドを見事に構築しています。 3 ページ程度の 内容て、すが , その中に Turbo Pascal Ver. 5.5 のプログラムソースも含まれています。 解説を読むよりも直接プログラムを見たほ うが理解しやすいかもしれません。

00 ー 0 十っ Fig. 1 C 十十のコンバイルプロセス も , その処理系がなければ , プログラミン 0 「 1 ロロ という問題がある 仕様が決定されて C 十十の誕生にあたっては , 処理系の実現 号て、解説する予定て、ある ) 。 るために加えられた機能てある ( 詳しくは次 オプジェクト指向プログラミングを実現す なり , C 十十独特の表現が多いが , これは , れらは , オプジェクト指向ての表現とは異 クラス ( 導出クラス ) などの機能て、ある。 しての要素とは , クラス , スコープ , 派生 当然備えられている。オプジェクト指向と とから , オプジェクト指向としての要素も ト指向プログラミングのサポート」があるこ しかし , C 十十の目的として「オプジェク 解いただけるて、あろう。 れ , 誕生したものて、あるということがご理 ものて、はなく , よりよい C 言語として設計さ ト指向プログラミング言語として生まれた 以上のことからも , C 十十は , オプジェク どの機能が盛り込まれている。 ジェクト指向を意識しデータ隠蔽や継承な 抽象化」をサポートし , その延長としてオプ いる。新しい機能の追加として , 「データの 「さらに , よりよい C 言語」の実現を目指して た , 改善のみて、なく , 新しい機能を追加し , ータ型チェックの強化」を行っている。ま に対するあいまいな処理の改善策として「デ 位互換性」を保ち , C 言語の欠点て、ある , 型 C 言語の特徴をいかすために , 「 C 言語との上 めのアプローチて、あるということて、ある。 は , すべてが「よりよい C 言語」を設計するた さて , 前述した項目についていえること を込められて設計されたのて、ある。 このように , C 十十には , さまざまな期待 グ言語とはいえない。 C 十十の処理系は , C のプリプロセッサとして実現されている。 C 十十コンパイラは , C 十十のソースコード からオプジェクトコードを生成するものて、 はなく , C のソースコードを生成する。その コードを通常の C コンパイラて、コンパイルす ることて , C 十十のコンノヾイルのプロセスが 終了する (Fig. 1 参照 ) 。 このことからも , C 十十が拡張 C 言語て、あ るといえる。また , C 十十コンパイラが C の プリプロセスとして働くため , C のコンパイ ラが動作している機種に容易に移植するこ とがて、き , そのため , C 十十が C 言語ューザ に幅広く使用される時期が近く訪れると思 とめてみる。 C 十十の特徴 ( C 言語の特徴を除いた ) をま C + 十の特徴 われる。 ための機能が追加されている ③オプジェクト指向的プログラミングの されている の記述や変数の宣言などの記述が追加 ②可読性を高めるための新しいコメント している ① C 言語に比べデータ型のチェックを強化 にまとめられる。 機能を追加している。それらは , 以下の 3 点 の弱さなどの改善を行うと同時に , 新しい し , また , C 言語の欠点てあった型チェック 上位互換性を保っことて℃言語の特徴をいか 前項に示したように , C 十十は , C 言語と まずデータ型については , C て、は , 代入や 演算の際に可能なかぎり暗黙の型変換が行 われ , 関数呼び出し時の引数て、は , データ 型のチェックがコンパイル時に行われない ために , 誤って異なった型のデータを引数 とした場合て、も , そのままコンパイルされ , 実行時にまちがった実行結果が得られるこ とになる。 C 十 + て、は , 関数の引数の型チェックを「関 数のプロトタイプ宣言 ( 関数の型宣言 ) 」によ って行っている。また , 演算においても , データ型のチェックを強化することて、コン パイル時に多くのエラー ( バグ ) を発見する ことがて、き , 信頼性や移植性を高いものに している。 次に , コメントの記述や変数の宣言にお いて , C と同様の記述は残されているが , 新 しい記述を設けている。 C て、の変数の宣言は 最初に行わなければならないが , C 十十ては 一般の式と同等に扱われ , 式を記述て、きる ところに変数の宣言を行える。このことて、 プログラムの可読性が高められることにな る。 また , オプジェクト指向的プログラミン グを実現するための機能が追加されている。 追加されているのは , データの抽象化を行 うためのクラスと呼ばれる特殊な構造体の 定義や , クラスによりデータのプロテクト が行えるなどの機能て、ある。 上記の特徴を , C 言語の機能を拡張した部 分と新しい概念の導入に分け , 今回はどの ような機能が拡張・追加されたかを , 次号 ては新しく取り入れられた概念により加え コメントの記述 ℃ + 十一℃ ] の機能 られた機能について解説する。 特集 C 十 + レポート 39 プログラム解析時に非常に有効な手助けと プログラム中のコメントは , デバッグや

いるマシンとデノヾッグ中のプログラムが実 て、すが , もちろん , これは C 十十から取られ StaIIman そう。そして互換性のない部 行されるマシンを変えられる機能て、す。す たものて、す。しかし , このような発想自体 分があるのは非常にばかげたまちがいて、す。 て、にリモートデバッグの機能はありますが , オプジェクト指向プログラミングに話 は , 何ト年も前から十指にあまるプログラ クロスデバッグが可能になれば , マシンの を戻させていただきますが , 数年くらい前 ミング言語に . まて、遡れるものて、すから , C 十十 種類も変えられるわけて、す。 にすべての名誉を与・えるわけにはいきませ から , MS-Corp. , Lotus Development とい 今のバージョン 3 にはない機能ですね ? った大規模なソフトウェアメーカーの多く んが。 Stallman はい , 今のバージョンて、はて、 が , 自社製品の宣伝文句として、、オプジェ C 十十についてはいかがですか ? 今 きません。もうひとつ考えているのは , C 十十 クト指向プログラミング〃という言葉を自 c 十十をめぐっては標準化が議論の対象にな のサポートて、す。 っていますが , 安定したシステムになって 由に使っています。一般的にいって , この いるのでしようか ? ような使い方はまちがってはいませんか ? オプジェクト指向 StalIman そのことについては何も知り Stallman C 十十には , 設計のますさのた フログラム めにまったく無意味な部分が含まれていま ません。商用製品がどうなっているかはフ す。ご存知のように , C 十十の背景には論理 オローしませんのて、。 c 言語の世界全体についてどう考えてお というものがありません。たとえば , C 十十 それでは , この世界にオプジェクト指 いでですか ? それから C 十十やオプジェク の文法はあいまいて、す。ある種の宣言とあ 向製品の名に値するものがあるとお考えで ト指向プログラムについてはいかがですか ? る種の変換を区別するには , 発見的方法を すか ? ソフトウェアメーカーはちゃんと Sta Ⅱ ma n オプジェクト指向プログラミ 使わなければなりません。また , C との間て、 それらしいものを作っているのでしようか ? ングが有効なのは , 主としてコンパイル時 も無意味なところて、互換性が失われていま それともたんに用語の問題だということで にオプジェクトのデータ型を決められない す。たとえば , C 十十て、構造体 , 共用体を定 しようか ? 場合て、しよう。コンパイル時がだめなのて、 , 義すると , 自動的に型宣言にもなってしま StaIIman そのようなことは研究してい 実行時に型チェックを行うわけて、す。コン います。これて、は , ちょっと大きな C プログ ません。 パイル時に型チェックをするなら , 構文に ラムは , C 十十て、は動かなくなってしまいま あなたは , プログラミング環境の新世 代に関わっていても , ソフトウェア産業の 味をつけて , 名前のつけ方を変えただけに す。このようなことをする理由は見あたら すぎません。これは , 1980 年ごろにオプジ 世界で起こっていることは本当にご存知な ないのて、す。 C とほとんど同じて、 , あらゆる意味て℃の ェクト指向プログラミングシステムとウィ いのですか ? ンドウシステムを 1 , 2 種類作ったときの経 Stallman いいえ , かなり知っています よさを引き継いて、おり , しかも上位互換性 験から得られた結論て、す。 をもっ言語は簡単に作れたはすなのて、す。 よ。私は自分が作ろうとしているプログラ オプジェクト指向プログラミングはウィ しかし , c と c 十十の両方の開発に密接 ムのためのアイディアを得るというところ ンドウシステムなどに適しています。ウィ て、しか , 商用ソフトウェアには関心がない に関係し , その種の不一致を洗い出す委員 ンドウシステムて、は , 既存のコードやウィ のて、す。しかし , 私の知るかぎり , 一部の 会があります。今いわれたような問題は , 人が作ったオプジェクト指向プログラミン ンドウシステムを利用して動作する新しい これらの委員会が是正していくのではあり グシステムは , 本物のオプジェクト指向プ ウインドウの型が定義て、きるようになって ませんか ? Stallman そうかもしれないけど , て、き ログラミングシステムにまちがいありませ いるのが望ましい。ウインドウシステムは , まだ存在しないデータ型を許容て、きなけれ るのが遅すぎましたよ。もう委員会がて、き んよ。て、も , 問題は , それがいっ便利て、何 ることなんかないて、しよう。 をするときに便利て、何を目的としているか ばならないのて、す。 ということて、しよう ? しかし , あらかじめデータ型がわかって PortabIe C のような新しい分野なら , いるようなプログラムにまて、オプジェクト C 十十は , コンパイル時に型がわかるとい これらの委員会が何か正しい決定をするチ 指向の技法を応用するのは行きすぎて、まち うことを目的としています。前にもいった ャンスがあるんじゃないですか ? どう思 ように , それて、は構文に味をつけて , 名前 がいだと思います。このような場合は , ど われます ? StaIIman ANSI C の標準 C はあるけれど のような引数を取るどのような関数を使う のつけ方を変えただけにすぎません。その ということを示す宣言構文を使えばよい 意味て、は , C + + は何が本当に便利なのかと も , C 十十とは何の関係もない いうところて、まちがった考え方のもとに設 実際 , プロトタイプ宣言を使うとまちがい 確かに c 十十の骨組はもう固まってしま が減ります 0ANSI C のプロトタイプのこと されていると思います。 っていますね。 ・巻頭インタビュー 17

0 1990 年代はオプジェクト指向プロ グラミング , とくに C 十十の時代だといわれて いる。しかし , オプジェクト指向言語として c + + をとらえるあまり , スムーズな C からの移 行が阻まれているとも指摘される。 C 十十プロ グラミング実現に必要なものとは・・・・・・。本特集 では拡張 C 言語としての C 十十にスポットをあ てたのち , C + + コンパイラの実態を考察する。

拡張 C としての C 十十 P A R ー 龍崎昌平 C 十十はオプジェクト指向プログラミング言語の面ばか りが強調されている。しかし , C 十十は , もともと拡張 C 言語として開発されたもので , その基礎はあくまでも C 言語である。本ノヾートでは , C 十十が C 言語とどこが違 い , どこが同じなのかを解説する。 ( アセンプリ言語のように ) の機械制御まて、 C 十十は , システム記述用言語として開発・ 記述することがて、きる。また , コンパイラ された C 言語の後継言語として , C を開発し 自身が C 言語て、記述されているため , 移植性 た米国 AT&T BeII Laboratoris から , Bjar の高いプログラミング言語て、ある。 ne Stroustrup の設計により , 1983 年に発表 された。 C 十十の誕生以前には「 C with class 」 プログラミング言語 C 十十については , 本 こうした特徴をもっ C 言語を基礎言語とし 誌をはじめ , すて、にいくっかの雑誌て、幾度 て新しく設計された言語が C 十十て、あり , C と呼ばれる言語が 1980 年に発表され , これ も取り上げられており , また , 関連書籍も が C 十十の設計時のべースになったといわれ 言語を基本概念としていることから , C 十十 多数刊行されている。しかし , C 十十をオプ ている。また , 設計には 3 つの条件を盛り込 は C 言語の拡張版と位置づけられる。 ジェクト指向プログラミング言語としてと C 十十をオプジェクト指向の立場て、解釈し んだといわれている。 らえているものばかりて、 , 拡張 C 言語として た場合は , C 十十のいくつかの機能がオプジ ①よりよい C 言語であること ェクト指向ととらえられ , オプジェクト指 とらえているものは皆無に近い ②データの抽象化をサポートすること 向的プログラミングが可能て、あるといえよ ③オプジェクト指向プログラミングをサ しかし , C 十十は , C 言語を基礎言語とし う。そうした点から , 「 C 十十はオプジェク ポートすること て設計されたプログラミング言語て、あり , ト指向型言語て、ある」という定義が多いが , ( 「プログラミング言語 C + 十の概要」 ( 原題 C 言語の基本概念が根底にあることから , オ こて、はこの定義をあえて否定し , 「 C 言語 、、 An OverView of C 十十〃 , 「日経エレクト プジェクト指向プログラミングのメカニズ を基礎言語とした C の拡張言語て、ある」と定 ロニクス』 1987 年 2.9 号 ) ムを直接もっている言語て、はない また , C 十十は次の目標を満たそうとして 義することから話をすすめる。 C 言語は , UNIX を記述するために開発さ れ , UNIX の普及やパソコンへの移植などに ① C 言語特有の極度に高い機械的効率と より , 現在てはさまざまなコンピュータ上 ポータビリティを維持すること て動くようになってきている。そして , そ の用途は , システム記述から通信 , テキス ロロ ③ C 言語の欠点である , 型に対するあいま C 十十の歴史については , すて、に多くの文 ト処理 , ウインドウシステムやプロセス制 献て、紹介されているのて、 , ここて、は C 十十に いな処理方法を改めること 御など , あらゆる分野て、使用されている。 ④ C 言語を最近のデータ隠蔽原則に従って どのような要素が盛り込まれているかを私 C 言語は手続き型言語て、 , 構造化プログラ 改善すること ミングを実現している。さらに , 低レベル なりに解釈してみたい 38 CMAGAZINE 1991 2 はじめこ C 十十の誕生

の高いプログラム記述が可能になるのて、あ Smalltalk-80 とは , 端的にいって計算機 て、動いているすべての機能を , オプジェク トによって記述したシステム , いわば計算 機をシミュレートしたシステムて、あるとい えよう。そして , SmaIItaIk ー 80 において , オプジェクト指向の観点からもっとも重要 なことは , プログラミングシステムをオプ ジェクト指向の考え方によって新しく作っ たことて、 , C 十十や Objective-C などのよう に旧来の言語処理系にオプジェクト指向の 考え方を取り入れたものて、はないというこ とて、ある。 このことの優劣や善し悪しは抜きにして , SmalltaIk ー 80 においては低レベルからアプ リケーションまて、 , すべてオプジェクト指 向によって記述されているため , 今後 C 十十 て、より高度なオプジェクト指向プログラミ ングを行う場合 , 実際的に不可欠て、あるク ラスライプラリ群を構成していくために重 要な手掛かりとなるて、あろう。 Smalltalk-80 システム SmalltaIk-80 のプログラムは , 仮想マシ ン上て、動く中間コードに落とされる。これ が , SmaIItaIk ー 80 のコンパイルて、ある。つ まり , SmaIItaIk ー 80 は仮想マシンというイ ンタブリタブログラム上て、中間コードが実 行するのて、あり , インタブリタ十コンパイ ラという構成になっている。この中間コー ド群を仮想イメージと呼んて、いる。 仮想イメージは , クラス階層と生成され たインスタンス群から構成されている。ユ ーザが Smalltalk ー 80 て、プログラムを書く場 合 , この仮想イメージの中に自己のプログ ラムを追加する。つまり , 既存のクラス階 層の中に , 自己の定義するクラスをサプク ラッシングによって追加し , そのインスタ ンス生成を行ってプログラムを実行するわ けて、ある。 Sma Ⅱ talk ー 80 のプログラミング は , システムへの追加という形て、行ってい くため , 仮想イメージの世界て、は , 「オプジ ェクト指向てプログラムを書く」という作業 と , 「オプジェクト指向を実現するプログラ ムを書く」という作業に区別がないのが特徴 て、ある。 ユーザが追加するプログラムは , SmaIItaIk ー 80 によって中間コードに落とされ , 仮想イ メージの中に追加されるのて、あるが , ソー スコードが失われると , デバッグなどの作 業において非常に効率が悪い。そこて , Smal ltalk ー 80 て、はソースコード群はファイルに格 納される。既存のクラスに関するソースコ ードは , 拡張子が「 . sources 」というファイル またユーザが追加したクラスに関する ソースコードは , 拡張子が「 . changes 」とい うファイルに格納される。 もちろん , このソースコードを管理する ファイルがなくても , 仮想イメージが存在 すれば , Sma Ⅱ talk ー 80 を動かすことがて、き る。それどころか , この仮想イメージから ソースコードを逆コンパイルして参照する ことも可能なのて、ある。ただし , この逆コ ンパイルの結果からは , メソッド内のコメ ントや一時変数の識別名などは失われてし まう。 なお , この仮想イメージは , 拡張子が「 . im 」のファイルに格納される。 このように , Smalltalk-80 の場合すべて のクラスは , 必ず何らかのクラスのサプク ラスて、あり , そのクラス階層の項点にある クラスは , Object というクラスて、ある。ク ラス Object は , オプジェクトとして仮想イ メージの中に存在するための最低限の情報 をもっている。たとえば , オプジェクトど うしの比較 , コヒ。ー , 表示 , 工ラー処理な どて、ある。 則回 , データ構造て、ある C011ection のクラ ス階層を示したが , 正確にはクラス C 司 lection のスーノヾークラスとしてこの Object がある のて、ある。ユーザが新たにクラスを定義す わジェクト指向 への招待 オプジェクト指向への招待 79 80 におけるこうしたプログラミング作業を ム構造を見つけ出すのて、ある。 Smalltalk- し , 試行錯誤的に行われて , 最適なシステ 適用されにくい。これらの作業が , 繰り返 法論て、ある , ウォーターフォールモデルが 業においては , システム開発の伝統的な方 ように , Smalltalk ー 80 のプログラミング作 ④がプログラミングになるといえる。この ③はフローチャート記述的な作業になるし , たるし , ②はシステム設計にあたる。また , ①の作業は , システム分析的な作業にあ ④オプジェクトの実装を行うこと ③オプジェクト間の関係を決めること ッド ) を決定すること ②オプジェクトの構造 ( 変数 ) と動き ( メソ ①オプジェクトを選び出すこと 以下の 4 つの作業て、ある。 プログラマが行わなければいけないのは , オプジェクトを中心に考えていくのて、ある。 う概念は , まったく考えない。あくまて、 , 場合 , C 言語とは異なり , データや関数とい する。 SmalltaIk ー 80 て、プログラミングする ー 80 によってプログラミングしていくこ それて、は , 実際に簡単な例を , SmaIItaIk 起こりがちなのて、ある , ー 80 のサプクラッシングが一致しないことが じ、 田考をしているのて、 , 思考過程と SmaIItaIk から抽象的なものへと , ポトムアップ的に とになる。ところが , 人間は具体的なもの トップダウン的に作業が進行するこ ないのて、 , プログラミングは抽象から具体 かのクラスのサプクラスにしなければなら ューザの定義するクラスは , 必ずなんら 抽象度が高いことになる。 構成されるものて、ある。上位のクラスほど , に , クラス階層は抽象化のレベルによって カニズムがくせものて、ある。前述したよう ラミングに際しては , このクラス定義のメ よいことになる。ところが , 実際のプログ の直接のサプクラスとして定義しておけば 定て、ある場合などは , とりあえすクラス Object る場合 , そのクラスの階層内て、の位置が未

くてはならない キーて、参照はて、きず , 要素の重複を許さな デイター十リファレンサー十工クゼックツ これらの作業が終わると , オプジェクト ールといった機能をもったものて、ある。と いものて、あるとするならば , それはクラス くに , Sma Ⅱ talk ー 80 のシステムプラウザ 相互の関係を考えなければならない。各社 「 Set 」としての性質をもったものとなる。 員は , クラス「技術系社員」か「スタッフ系社 は , マウスによるビットマップディスプレ れらのクラスのサプクラスとして「名簿」が 員」のインスタンスとして生成される。そし イのオペレーションと不可分な関係にある 定義されるのて、ある。 て , 名簿の中に束縛される。これが基本的 ということと , オプジェクトを単位として このように , サプクラッシングを行うこ なシステムの全体構造て、ある。オプジェク 編集したり , 参照したりするために , 特化 とて , 既存のクラス階層がもつ変数や手続 ト指向のもとて、 , 「もの」を基準にシステム しているということの 2 点において非常に特 きなどの性質が , ユーザによる新たな定義 なして , 再利用てきるのて、ある。もし , 「名 を整理していった場合 , 非常に構造が簡潔 徴的て、ある。 に表現て、き , 問題解決が非常に行いやすい Fig. 2 にその例を示すが , ますマウスオペ 簿」が , このようなデータ構造群のもっ特徴 レーションとの関係について考えてみる。 に完全にあてはまるものてあったとするな ことを理解していただけると思う。 オプジェクト指向技法自体は , たんなる オプジェクト指向を考察する場合 , オプジ らば , ユーザは「名簿」についてクラス定義 ェクト指向ユーザインタフェイスという概 プログラミングパラダイムて、はなく , 思考 だけを行えばよいのてあって , メソッドはま や問題整理の技法て、もある。なお , 最近は ったく記述する必要がないのて、ある。これが , 念がしばしば取り上げられる。 こうしたシステムの構造の表現技法などが , マウスを用いてアイコン , マルチウイン ①のオプジェクトの選定にあたる作業て、あ オプジェクト指向システム分析 ( OOA ) として ドウなどを操作するような , いわゆるアイ る。これは , たとえば「名簿」ならば , 名簿 研究されているが , まだ確定的なものは存 コニック環境は , 一般に使い勝手のよいも というものは , どういう性質をもったもの かということを明らかにする作業て、もある。 在していない のて、あるとされる。 しかし , はたしてそうて、あろうか。まず , Smalltalk-80 の , とくにアプリケーショ SmalltaIk-80 20 年も前ならばいざしらず , 現在は計算機 ンプログラムの善し悪しは , 実はこのクラ プログラミング ことにオフィスな はかなり普及しており , スの選定て、あらかた決定してしまう。その らば , だいたいどこて、もパソコンぐらいは ため , 実際のプログラミング作業て、は , ある。大部分のユーザにとって , 計算機は 最後に , オプジェクトの実装 , すなわち のクラス階層の検討が繰り返し行われるこ それほど珍しいものて、はなく , 標準的なキ とになる。ところが , Smalltalk ー 80 て、はト プログラミングが行われる。 Smalltalk-80 ャラクタベースのユーザインタフェイスも , ップダウンてクラス階層を決定しなければ の場合 , この作業について解説されること ならないため , なかなか最適なクラス階層 それほど不便なものとは感じてはいないの が非常に多かった。それは , Smalltalk-80 に SystemBrowser( システムプラウザ ) とい が決定しにくい こうした状況下において て、はなかろうか。 マウスを用いたオペレーション自体 , あま 次に , ②オプジェクトの構造 ( 変数 ) と動 う , 強力なツールがあるからて、ある。本誌 り魅力的なユーザインタフェイスて、はない ' 90 年 12 月号の「 Computer Language 」提携 き ( メソッド ) の決定を行うことになる。上 記事「 C 十十や PascaI にもプラウザ環境を」か 己したように , 社員自体がデータを管理す ように思われる。 ら若干引用したい。「ひとつのプロジェクト 実は , アイコニックオペレーションは , るため , クラス「社員」は , 名前 , 社員番号 , オプジェクト指向と結びつくことにより , 給与の 3 つの情報を保持するための変数域が て、 , 25 から 30 くらいのファイルに , 90 ない 初めてそのパワーを発揮されるのて、ある。 し 100 個のオプジェクトがあり , それらの多 必要て、ある。そして , クラス「技術系社員」 は言語と経験年数を , クラス「スタッフ系社 くが互いに派生 , 導出の関係にある・・ Fig. 3 に示したのは , アイコニックオペレー 員」は所属部門の情報を保持するための変数 ションが行える代表的な計算機システムて、 ういう複雑な開発作業それ自体に , 高度な オプジェクト指向の技法を応用して , 見通 ある , 富士ゼロックス社のオフィスワーク が必要となる。 ステーション J ー Star の画面イメージて、ある。 しよくエ程を進めることはて、きないものて もちろん , これらの内部変数に対して , ここに小されているいくつかのシンポルが しようか。ひとつの解答が・・・・・・プラウザて 参照と値の変更を行うための手続きが必要 す」 ( P. 20 ) 。 アイコンと呼ばれるものて、ある。アイコン になることは , 前回述べたとおりて、ある。 まさに , システムプラウザは , そういっ とは , ファイルやディレクトリ , 周辺機器 また , クラス「名簿」は , 各社員オプジェク た機能をもったツールて、ある。システムプ トを保持するための変数が必要て、あり , 社 など , ユーザがその画面を通じてアクセス ラウザとは , ひとことて、いって , 構造化工 て、きる計算機資源を記号化したものてある。 員の追加や削除 , そして参照などがて、きな 一三ロ 82 CMAGAZINE 1 1 2

という ジニアには , 非常に馴染みにくい のは , ソフトウェア工ンジニアには , 厳然 とした職域があるからて、ある。 ソフトウェア工ンジニアの職域は , 現在 の計算機ソフトウェアの構造や機能に密接 に対応している。計算機上のソフトウェア には , 低いレベルからよりユーザに近いも のまて、さまざまな種類があり , 極端に言っ てしまえば , それらがすべて別個のプログ ラムになっているため , それを開発する人 間も別々なものになるのて、ある。 ところが , 使う側にとって , それは大き な障害になる。たとえば , あるプログラム を C 十十て、書いて , それを実行させたいと思 った場合 , C 十十のシンタックスがわかって いてもだめて、ある。まず , 編集をするため のエデイタの操作がて、きなくてはならない し , 当然デバッグしなければならなくなる て、あろうから , デバッガの使い方も理解し なければならない。そして何より , その前 提として , コンパイラやそれらのツールを 動かすために , OS の操作もて、きなくてはな らないのて、ある。 C 十十の言語解説には , ます工デイタの操 作などは含まれない。それは言語処理系と は別のプログラムだからて、ある。それに対 し , SmalltaIk-80 は , それら個別のプログ ラムをすべて含んだシステムて、ある。今ま て、 , 多くのプログラムによって行われてき た計算機のさまざまな機能を , Smalltalk- 80 というひとつのプログラムが行うのて、ある。 こうした考え方は馴染みにく い。しかし , たとえば現在のワークステー ションて、の開発を考えた場合 , 実質的に別 個のプログラムが統合化されているのに気 づくて、あろうか。 UNIX が , ワークステーションの標準 OS といわれている。 UNIX を採用した場合 , 開 発言語は C 言語が採用されるし , ューザイン タフェイスとしては , X-Window などが選 ばれ , デバッガとしては , dbx などのシンボ、 リックなデバッガが選ばれる。そして , お 78 CMAGAZINE 1991 2 のおののソフトウェアは , 相互を想定して , ライプラリなどの形て、 , ソフトウェア間の インタフェイスを用意しているのて、ある。 機能に応じた標準的な構成が決まってしま うわけて、あり , そうすると , それらのプロ グラム群は実質的にひとつのプログラムて、 あると考えることがて、きる。 Smalltalk-80 は , まさにこのことを実現しているのて、あ る。 言語処理系十ウインドウシステム十デバ ッガ十ユーティリティ十グラフィックツー ル十 OS=SmaIItalk-80 ということになろう か。 SmalltaIk ー 80 の言語解説書と呼ばれる ものには前記のプルーブックのほかに , オ ペレーションマニュアルに該当する , 通称 オレンジブック ( 「 Smalltalk-80 対話的プロ グラミング環境」 , Goldburg, A. 著 , オーム 社 ) が存在し , 同書の Smalltalk ー 80 の言語解 説部分に , 本連載第 1 回て、示したウインドウ の図が現れてくるのはそのためて、ある。 SmaIItaIk-80 の機能を , プルーブックも 含め多くの解説書て、は , 「環境」と呼んて、い る。しかし , 「環境」という用語て、は , シス 言語処理系て、あるというこ テムの実体と , とが , どうもしつくり結び付かない。計算 機の世界には , SmaIItalk ー 80 の正体を端的 に表現するための用語が存在していないの て、あろう。 ただし , こうした機能を 1 本のプログラム て、実現するためには , ふたつの大きな障害 がある。まず , Smalltalk ー 80 はさまざまな 機能を統合した 1 本のソフトウェアて、あるた め , 現在のハードウェアて、は , 完全に動か すことが不可能に近いということて、ある。 言語処理系とウインドウシステム , ユーテ ィリティなどが一度に動くのて、あるから当 然て、あるといえる。また , OS からウインド ウシステムまて、すべてを含んて、しまうため , SmaIItalk ー 80 は巨大なプログラムになって しまうということも指摘て、きる。これらは , 同じ問題を前者はハードから , 後者はソフ トの観点から見た問題て、あるといえるかも しれない 前者のハードウェアの間題は , 実はソフ トウェアによって解決されている。ソフト ウェアによって , Smalltalk ー 80 の言語仕様 に耐えられるようなハードウェアをエミュ レートするのて、ある。これを , 仮想マシン と呼んて、いる。 SmaIItaIk ー 80 を移植すると いうことは , この仮想マシンを移植するこ とになる。この考え方によって , Smalltalk ー 80 はその名前のとおり , 1980 年当時のハー ドウェア技術にもかかわらす , 高度な言語 仕様をもちえたのて、ある。 一般に , ソフトウェアの仕様はハー ェアの能力に依存してしまう。私たちもソ フトウェアの仕様を考える場合 , ューザの 要求 ( ニーズ ) よりも , ハードウェアの性能 ( シーズ ) を重視してしまいがちて、ある。し かし , Smalltalk ー 80 の開発者たちは , この 点て、妥協しなかった。ソフトウェア工ンジ ニアとして , 考えさせられる点が多い 最近て、は , この仮想マシンを直接実行し てしまう Smalltalk チップなどの研究も行わ れている。ただし , この仮想マシンは , オ プジェクト指向とは直接関係がない。ター ゲットマシンに依存しているため , 言語仕 様を効率的に実現すればよいのて、ある。 後者のソフトウェアに関する問題を解決 したのが , 実はオプジェクト指向て、ある。 SmalItaIk-80 は , オプジェクト指向て、プ ログラムを書くための言語処理系をオプジ ェクト指向によって実現したプログラムな のて、ある。 SmalltaIk ー 80 自体 , オプジェク ト指向によって誓かれている。より詳しく いえば , SmaIItalk ー 80 は Smalltalk-80 に よってかれているということになる。 れが Smalltalk ー 80 の正体て、ある。過去に オプジェクト指向て、書かれた , 最大のプロ グラムは Smalltalk ー 80 て、あるといわれる のは , このことを意味している。ソフトウ ェア開発にオプジェクト指向を導入するこ とにより , 高度な部品化を行うことがて、き るため , 巨大なシステムて、あっても信頼性