特集℃言語とオプジェクト指向 メモリに余裕があるにもかかわらず , すべ て使い尽くしてしまうという可能性が生じ てしまう ) 。ガべージコレクション機能は , 本来は OOP には不可欠のものて、あると考え ている。 しかし , C 十十て、は , ジコレクションがサポ 語としてはガべー ートされていない C 十十にはコンストラクタと対になるデスト ラクタという機能があるのだが , 自動的な ガべージコレクションは行えない。結局 , C 十十て、は , プログラマが注意深くメモリの 解放のタイミングを考慮して , 自ら明示的 にコーディングするしかない。しかも , ス タック上に割り付けたオプジェクトと , ヒ ープ上に割り付けたオプジェクトて、は , 取 り扱いを区別しなければならない。ガべー ジコレクションをサポートしない代わりに C 十十は高い実行効率を得られるとされてい るものの , 本格的な OOP を行うときには , この状態は誤りを引き起こしやすく , 決し て望ましいことて、はないと筆者は考えてい だが , C 十十て、すら言語て、サポートしてい ないくらいだから , C の場合にも , もちろん ロ語としてのガべージコレクションのサポ ートはない。ただし , malloc などのメモリ 割り付け関数にライプラリをかぶせて , ガ べージコレクション機能を実現することは て、きるだろう。 だが , 残念ながらその技法に触れている 余裕はなくなってしまった。また , 今回の プログラムはすべてオプジェクトをスタッ クに割り付けているのて、ガべージコレクシ ョンをする必要はない。しかし , 将来 , も っと高度な OOP を行う際には , ぜひ考慮し まとめ てみてほしいテーマて、ある。 ても実現て、きる範囲の OOP の例を示してみ C 言語を用いて , 必要以上に無理をしなく かっては Smalltalk など , 特殊な言語を用 いないと実現て、きないと思われていたこと もある OOP て、あるが , 本質的な特徴に絞れ ば , 普通の C て、も十分プログラミングは可能 て、あることがおわかりいただけたと思う。 オプジェクト指向は , 語の実装レベルて、 はちょっとした仕掛けて、しかない だが , その背景にはプログラミングパラダイムの 大きな変化がある。そしてそれが , 結果的 にドラスティックな生産性の向上を生み出 すにともある , というのが正確なところだ ろう ) 。 オプジェクト指向パラダイムへの批判と して , 「主と従の関係が変わっただけて、はな いか。従来は手続きが主て、 , データが従だ ったのを逆転させただけだ」という主張があ しかし , ときとして縦のものを横にする のて、すら多大な労力を要するように 主と従の逆転はたいへんな発想の転換なの だ。受け身だったデータが , 能動的な存在 としてのオプジェクトへと変身を遂げたの て、ある。これは決してつまらない違いて、は ない。パラダイムが変化することて、 , プロ グラミングがこれだけ変わるのかと驚かさ れるのがオプジェクト指向の特徴だと思う。 ただし , OOP は , オプジェクト指向設計 と対になって , 初めて最大の効果を発揮す るものて、あることを指摘しておきたい。単 に「オプジェクト指向言語なるものが流行し ているようだから , ひとつオプジェクトを 使ってプログラムを作ってみるか」という動 機て、取りかかるのて、は , 喧伝される OOP の メリットーー一生産性の飛躍的な向上は得ら れないと思ったほうがよい いい換えれば , OOP とは , 単なるプログ ラミング言語に備わった「機能」て、はなくて , ソフトウェアの構造に対する「考え方」て、あ り「思想」なのて、ある。思想が身につかない いくら道具を振り回したところて、 ダメて、ある。 そういった観点からすると , 思想を学ぶ には , やはり Smalltalk のように純然たるオ プジェクト指向言語が最適だと思う。非オ プジェクト指向言語を拡張してオプジェク ト指向の機能を与えた , いわゆるハイプリ ッド型の言語を利用する場合には , どうし ても従来型のパラダイムからの影響が強く なり , オプジェクト指向の本質が見えにく いのて、はないかという点が心配になる。と くにハイプリッド言語の代表て、ある C 十十の 場合には , C に対して , オプジェクト指向機 能以外にも多数の拡張を施している。それ ら豪華絢爛の機能が目の前て、渦を巻いて , 本質を見逃すことになりがちて、はないかと 危惧している。 て、あるから , 純粋なオプジェクト指向言 語が使えない場合て、も , て、きれば最初は , ごく素朴なオプジェクト指向機能しか持た 言語を利用して , その本質の把握に努 めたほうがよいように思う。 本章て、紹介したような技法は , ある程度 OOP に対して確固たる見通しを持っていな いと利用しにくい。この意味から , OOP の 入門に向いていると断言て、きないのは残念 だ。 だが , これを機会に , ぜひ何らかの形て、 OOP を試してみてほしい。そして , その本 質が何て、あるのかをぜひ見極めてほしい 本特集がそのお役に立てれば幸いて、ある。 なお , もう少し実用的なプログラムを例 題として , オプジェクト指向設計を採用し た場合に , どのようにコーディングが変わ るのかを示すサンプルを作成してみた。同 じ問題 , こて、はファイルに含まれる文字 数 , 単語数 , 行数をカウントする word cou nt というプログラムを , C による非 00P 特集 C 言語とオプジェクト指向 59 のて、 , 比較して参考にしていただきたい とがて、きないが , 付録ディスクに収録した 誌面の関係て、本誌にリストを掲載するこ る。 という 4 種類にわたって作成したものて、あ C 十十による 00P C による動的結合 00P C による静的結合 00P 風

を ロロ ・ 0 「 EO F まで繰り返せ」 生ロ い口 。第翡回一 今回は繰り返しを学習しましよう。繰り 返すというと fo 「文かありますが , 今回 は wh ⅱ e 文というものを使ってみます。 くまず覚えてみる。それからそのプログラ のポイント ムの動きを考えてみる。そして自分の手を 実際に動かしてプログラムをコンパイルし ホワイル 今月は「 EOF まて、繰り返せ」と題して while て実行してみる。それがプログラミング言 語を学ぶ王道といえましよう。 文について説明します。 while 文はある処理 初めは誰しも初心者て、す。初めて習う構 を繰り返して行いたいときに使う構文て、す。 文は , なじみがなくて当然て、すから , 慣れ 「繰り返し」といって思い出すのは for 文て、す と根気が必要て、す。 が , while 文も繰り返しを行います。 for 文と それて、は , 今月のレッスンを始めましょ while 文の違いについては後て、お話します。 whi 厄文の構造 めに C 言語の勉強は進んて、いますか ? もしか したら , 「何だか難しくなっていやになって きた」と思っていませんか ? そんなときは どうしたらいいて、しようね。 「何となく難しそうだ , めんどくさいな」 としていいかげんに進むのはあまりよい方 法て、はありません。ずっと勉強していて , ココまて、はわかるけれど , ココからがわか ' ューコーナー いきなり本題に入りましよう。 while 文の らないという分岐点が必ずあるはずて、す。 構造は次のようになっています。 難しそうな用語だとか , めんどうそうなプ ログラムに惑わされると , つい「覚える・考 先月の復習から始めます。先月のレッス while ( 条件 ) { ンて、は「関数」について学びました。 える・やってみる」という基本を忘れてしま 繰り返す処理 私たちが C 言語て、プログラムを書くとき , いがちて、す。 必ず printf( ) とか gets() といった関数のお 取り上げられているプログラムをとにか 世話になります。先月は関数を使うだけて、 初めに while と書かれています。これは「ホ while の例 ワイル」と読み , 英語て、「・・・の間」という意味 はなく , 自分て、関数を作る方法について学 を持っ単語て、す。 C 言語て、は「ある条件を満 びました。関数の三つのポイントを覚えて たす間繰り返す」という意味を持っ単語にな いますか。 っています。 while という語て、始まるのて、こ ・関数の宣言 ・関数の定義 の繰り返しの構文は「 while 文」と呼ばれてい ・関数の呼び出し ます。 if 文が if て、始まり , f 。 r 文が for て、始ま っているのに似ていますね。 ・引数 while の後には、、 ( クと、、 ) 〃て、括られた部分が ・戻り値 (return 文 ) こには , 繰り返しを行う条 出てきます。 件が書かれています。その後には、、 { 〃と、、 } 〃 という用語も覚えました。 List0 1 : #include く stdio. h> 2 : 3 : void main(void); 4 : 5 : void main(void) 7 : int c; 8 : c = getchar() ; 9 : while (c ト 10 : printf( ” ' Xc' %n ” , c) : 11 : c = getchar(); 12 : 13 : 14 : ) 90 C MAGAZINE 1993 11 レスン

Part サ月 ObJectiveC トランストタ ℃ PEY 」の開発 安達清弘 ( 有閑人 ) 口一◇ーロ「。。几口一 0 →◇ 純オプジェクト指向言語とい われる Smalltalk も , イン タブリタを必要とするがゆえ にポータビリティに欠け , 実 行速度が遅いなどの弱点があ る。本章では Sma Ⅱ t 引 k の オプジェクト指向言語として の利点と C 言語の優れたポー タビリティ , 実行速度を兼ね 備えた ObJectiveC トラ ンスレータ「 OPEY 」の開発 を通して 00P の一面を探る。 60 C MAGAZINE 1 3 11 2 ・一開発の動機 る必要がある。そのため , アーキテクチャ 語て、は , OS との間にインタブリタが介在す 作させることがて、きるが , インタブリタ言 ログラムを OS 直下て、スタンドアローンに動 C のようなコンパイラ言語は , 作成したプ する点て、ある。 る。それはこの言語がインタブリタを使用 この親愛なる言語 Smalltalk にも欠点があ に大きな影響を与えてくれた。 て、あり , 筆者のプログラムに関する考え方 チ ( いわゆるオプジェクト指向 ) を持つもの ラミング言語とはまったく異なるアプロー とくに最後の Smalltalk は , 従来のプログ SmalItaIk LISP Prolog のが以下に示す 3 言語て、ある。 の中て、目からウロコが落ちるほど感動した グラミング言語を勉強してきたが , これら している。その間 , 筆者はいろいろなプロ のつき合いは , もう 10 年以上にもなろうと いわゆるコンヒ。ュータといわれるものと Fig. 7 OPEY の処理概要 ければならず , プログラムの可搬性が損な われがちになる。 ある。このような点から , わが親愛なる Sm 一般的にコンパイラ言語より低速て、 中間言語を用いるインタブリタ言 語は , また , ・ ObjectiveC タイプのメッセージ式を通常 イラ (mkcls) 義ファイルを処理するクラスプリコンパ ・クラスを作成する際に記述するクラス定 て、 , 以下に示すものから構成されている。 もどきのプログラムを可能にする開発環境 一般的な ANSI C コンパイラて、 Objective C Environment by Yu-kan-jin の略称 ) とは , OPEY (Object oriented Programming Y て、ある。 い。そこて、 , 一念発起して作ったのが OPE 曜プログラマが手に入れられるものて、はな て、しか見ることがて、きず , 筆者のような日 tiveC の処理系は一部のワークステーション 世の中は C 十十が全盛て、あり , また , Objec ころ , Objective C が見つかった。しかし , を兼ね備えた言語はないものかと探したと と , C の可搬性およびコンパイラ言語の性質 SmalltaIk のオプジェクト指向の考え方 alltalk は実用的て、はないといわれている。 ba 「 . OC f00. cls f00. OC mkcls methods. nam F00. oh bar. C f00. C F00. h libOOPS. a CC a. out ※ f00 , F00 , ba 「は名前の例 mkcls f00. cls bar. CC OPP OC libOOPS. a クラスプリコンパイラ クラスライプラリ クラス定義ファイル クラス F00 の OPEY 用ソース システム ANSI C コンバイラ プロセッサ オプジェクトプリ

特集℃言語とオプジェクト指向 に , 制御構造とデータ構造を抽象化するこ 文をひとまとめにして , ひとつの文として さらに , データに関する操作は , データ 解釈するという ( 複合文 ) 機能を実現した。 とによって , 一段と洗練された言語 (Pasca とはまったく無関係の場所て、定義しなけれ すなわち制御構造の抽象化て、ある。 I) が生まれた。 ばならなかった。つまり , データと操作の また言語の設計者は , これら制御構造の 間にソース上て明示的な関連を示すことが 抽象化と同時に , FORTRAN の素朴なデー ・抽象データ型言語 て、きす , あるデータに施すことが可能な操 タ構造にも着目した。当時の FORTRAN の 次のステップは , データの抽象度をし 作が何て、あるのかが判然としないばかりか , 、つ データは , 単純な変数 ( スカラ ) か , あるい そう上げることて、あった。 PascaI て、は , ア、 あるデータが書き換えられたときに , それ はスカラの ( 1 , 2 , 3 次元の ) 配列だけて、あ ータの静的な構造は抽象化された。しかし , がどこて、行われた操作なのかがわかりにく その構造型はたんに要素を寄せ集めただけ いという欠点があった。 この点に関していえば , 構造化言語の始 て、ある。全体をひとつの型として扱うこと 抽象データ型はこのような背景から生ま 祖て、ある Algo ト 60 も , データ構造に関して もて、きるが , 外側から個々の要素にアクセ れてきた。これはその名のとおり , データ は FORTRAN と大同小異て、あった。そこ スすることも簡単て、 , 好きなように値を書 の構造だけて、なく , データの型そのものを て、 , データ構造を抽象化し , 構造体やポイ き換えることも可能て、ある。いい換えれば , 抽象化する機能て、ある。データ型の定義を , ンタ , あるいはそれらの配列 , およびそれ 外側から中の構造がどうなっているか , ど そのデータ型に適用可能な手続きと一体に らを再帰的に組み合わせて構成する , いわ のように型が実装されているかという具体 して行い , かぎられた特定の手続きのみが 的な情報が丸見えて、あった。 ゆる構造型というものを考えた。このよう データの内部構成要素をアクセスて、きるよ うにしたのて、ある。これによって , 構造を Fig. 1 プログラム言語における抽象化の歴史 持った型て、あっても , 外部からは中の実装 を伺い知ることがて、きなくなり , より抽象 度の高い実体となったのて、ある ( 抽象化と は , 必要のない , 物理的・具体的な情報を 捨て去る作業て、ある ) 。 ・オプジェクト指向言語 抽象データ型の後に続くのが , オプジェ クト指向言語て、ある。オプジェクト指向言 語て、は , 抽象データ型言語に対して , さら にデータと手続きを一体として抽象化した 存在「オプジェクト」を導入したところが最 大のポイントになるだろう。 たったそれだけの違いともいえるのだが , データと手続きが一体化したために , プロ グラムの構造は大幅に変更されることにな オプジェクト指向言語て、は , 従来の言語 に見られたような , データ型を判別して , それに応じて適用すべき手続きを切り換え るといった作業を不要にした。データをど のように操作すべきかは , オプジェクト自 身が知っているのて、ある。これにより , 手 続き呼び出しはメッセージの送信という , より抽象化した概念て、置き換えられた ( メッ セージについては後述する ) 。 特集 C 言語とオプジェクト指向 33 機械語 。令痿五と , アドレスの抽象化 アセンプラ CPU アーキテクチャ ( プログラミングモテル ) の抽象化 初期の手続き型高水準言語 (FORTRAN 66 ) 制御構造の抽象化 テータ構造の抽象化 構造化構文を備えた手続き型高水準言語 (Pascal) テータの本格的な抽象化 型 タ 象 抽 手続き十テータの抽象化 オプジェクト指向言語 (Smalltalk, C 十十 )

- 集三一 一特一オ 4 オプジェクト 指向考察 きだあきら 将来的にオプジェクト指向プ ログラミングが広く普及して いくであろうことは , かなり 確度の高い予測とされている。 本章ではオプジェクト指向プ ログラミングの真のメリット とは何なのかを , 抽象化の歴 史なども含めて探っていく。 プジェクト指向言語によるオフジェクト指向プログラミンク ( 00P ) 最大のメリットは生産性の向上だといわれる。保守性の 口上高いリ用性。ところが , オフジェク旨向言語のセ ルスポイントとされるこれらのメリットを , 使い慣れた C 言語 。実現する技法が右在る C 言語による 00P の実践である 当然 , 非オプジェクト指向言語である C 言語での 00P には限界 ヾあるのも事実だ。しかし本来オプジェクト指向とは単なる 技法や機能にあるのではなく , ソフトウェアシステムの分析 , 言をも含めたひとつの思想」といってもよい。その思想の に行われる C プログラミングによって , 漠然としていた 00P の の、を浮き彫りにるのが集の狙いである。 30 C MAGAZINE 1993 11

特集℃言語とオプジェクト指向 実行して初めて型が定まる。すなわち動的 にデータ型が定まるのて、ある。 例を示そう。 C て、「 x 十 1 」のような式があ ったとする。 見てのとおり , 何の変哲もない , 変数 x の 値に 1 を加えた値を計算する式て、ある。そし て C の場合には , もし x が「 intx : 」と宣口さ れていれば , こて、演算される型は int に定 まる。それはコンパイル時にソースを静的 に ( すなわち , 実行の手順を追ったりするこ となく , たとえばソースの先頭から順次見 ていくことて、 ) 解析すれば判明する。 て、 , 実際に実行してみると x には double 型の 値が格納されていたのて、 , 演算も double て、 行わなければならないなどということは , C ては決して起こらない。 C て、は変数 , すな わち入れ物に型がつけられていて , その中 身の型が何て、あるかは入れ物が決定するか らて、ある。 一方 , オプジェクト指向て、はない言語て、 あっても , 変数には一切型がないという言 語もある。そのような言語の中には , 型が 実質的にひとっしかないために , 型の区別 をする必要がなく , だから変数に型がない - —三五もあるが , 実際に複数のデータ といフⅱロ 型が存在するにもかかわらず , 変数にはと くに型を指定しないという言語もある。そ のような言語て、は , 変数という入れ物て、は なく , そこに入れられる実体 ( オプジェクト ) に型がついている。そのような言語の代表 としては , Lisp 系の言語がある。 Lisp 系言 語の , たとえば Scheme という言語て、は , 上 記の「 x 十 1 」に相当する式は「 ( 十 x 1 ) 」のよ うになる ( ただし , Scheme はオプジェクト 指向言語て、はない ) 。 ところが , Scheme て、は変数に型がつけら れていない。したがって , この加算をどの ようなデータ型て、行うかは , コンパイル時 には決定て、きない。たまたま x に整数が入っ ていれば ( Scheme 用語て、は「 x が結合してい る値が整数て、あったら」という ) , 整数の加 算が行われるだろうし , x に浮動小数が入っ ていたならば , 浮動小数の加算が行われな ければならない。 x がどのような値を保持し ているかは , ( たとえば , 直前て、整定数を代 入しているなどて、 ) 簡単に決定て、きる場合も あるだろうが , 一般には定めることがて、き このような場合 , x の型 ( および , 加 ない 算が行われるデータ型 ) は動的に定まるとい う。すなわち動的データ型て、ある。 動的データ型は , 一見ムダなように見え るかもしれない。コンパイル時に型が決定 て、きないということは , 実行時に型を調へ て振り分ける必要があるからて、ある ( これ を , オプジェクト指向ディスパッチと呼ぶ ことがある ) 。それはそのとおりて、あって , 若干実行効率的に不利て、あることは否定て、 しかし , オプジェクト指向言語に きない とって , 動的データ型は本質的な機能なの て、ある。その理由については , 以下に記し た動的結合の項を参照してほしい。そして 動的データ型さえあれば , 静的データ型は 不要て、ある。たとえば典型的かっ純粋なオ プジェクト指向言語て、ある Smalltalk て、は , データ型はすべて動的に定められ , コンパ イル時には一切 , 型の整合性のチェックは 行わない ・動的結合 より厳密な意味て、オプジェクト指向言語 の本質的な機能とは , 演算の対象になって いる変数の型て、はなく , 演算の対象になっ ているデータに応じて , 実行時に適切な演 算 ( 処理 ) を選択して行う機能て、ある。この 機能を動的結合 (dynamic binding) とか , 遅 い結合 ( late binding) とか呼ぶ。 これに対して , 変数の型によってコンパ イル時に演算が決定されるものは , 静的結 合 (static binding) とか早い結合 ( early bin ding ) などと呼ばれる。データに応じて処理 を選択するには , データそのものが「どのよ うに処理すべきかを知っている」ことにすれ ば話は簡単て、ある。「処理方法を知っている」 というのは , 現実には「どの手続きを呼べば よいのかを知づている」ということて、ある。 これがオプジェクト指向言語が , データと 手続きとを融合させて , 「オプジェクト」と して取り扱っている理由て、ある。この機能 があるからこそ , オプジェクト指向言語が オプジェクト指向になっているのだといっ ても過言て、はない オプジェクトが , 自分をどう処理すべき かの詳細を「知ってる」ことを利用すると , それを使う側て、は , 手続きの大枠だけを記 述して , あとの詳細はオプジェクト自身に 任せるということが可能になる。 たとえば , ( 例としては情けないのだが ) 「インスタントラーメンを作る」という作業 を考えてみよう。 この場合 , インスタントラーメンとーロ にいっても , 作り方は種々様々て、ある。カ ップ麺だけを考えても , お湯を注ぐだけて、 よいものもあり , 中から粉末スープの袋を 取り出して , それを麺の上に振りかけてか らお湯を注がなければならないものもあり , あるいは , ます「かやく」だけを麺の上に乗 せてお湯を注ぎ , 3 分間待った後て、液体スー プを入れるというものもある。 しかし , ラーメンを食べたくなって , 誰 かに頼んて、作ってもらうときに , わざわざ こんな細かいことを断わる人はいない んにカップ麺を手渡して , 「これ ( ラーメン ) 作ってよ」というだけだろう。そうすると ( そ んなことぐらい自分て、やれといわれないか ー ) ) , 数分後にはめて、たくラーメン ぎり にありつける。要するに処理の大枠を記述 しているのてある。 これをプログラム化するときには (C 十十 の場合 ) , 「 cupRamen. cook( ) ; 」などと , ラーメンのパッケージに直接「お願い」する ことにするか ( 現実には , お願いすればひと りて、にて、きあがってくれるような , そんな 便利なカップ麺は売られていないと思う ) , あるいは , 「作る人」というオプジェクトに 「 tukuruHito. cook(cupRamen) ・」とお願い することになるかて、ある。どちらになるか はプログラムの設計思想の違い ( と , その人 の家庭環境 ) によって変わるだろうが , 要は 「いちいち細かいことは具体的なモノに応じ 特集 c 言語とオプジェクト指向 35

作成されたに違いないだろうことを考えて ほしい。 ときと場合によっては , 実際この方法が 正解だということもある。自分が必要とす る機能だけを , 自分が好ましいと思う構文 て、提供て、きるからて、ある。ただし , トラン スレータの実現には膨大な開発コストを要 するのはいうまて、もない ( あえてそれに挑戦 したのが , 本特集パート 3 て、紹介している「 0 PEY 」て、ある ) 。 オプジェクト指向言語て、はない C て OOP を 行う場合 , リーズナプルなコストて、実現て、 きる機能にはかぎりがあることを認識しな ければならない。したがって , 用いること がて、きる機能に関して , 若干の制限が入る のは避けられない。この認識は重要て、ある。 コストを無視してコーディングのテクニッ クに走るのは本質を見失った行為て、ある。 必要なのは「 OOP 」て、はなく , 「 OOP を採用し た結果得られるメリット」て、あることを忘れ てはならない 抽象化に見る ープログラム言語の発展 OOP のメリットを論じる前に , それが発 展してきた背景を考えてみよう。遠回りの ようだが , この考察をすることて、 , オプジ ェクト指向の本質が見えるのて、はないかと 期待するからて、ある。そして , 本質が理解 て、きていなければ , 真のメリットを見いだ すことはて、きないに違いない 私見て、は , オプジェクト指向はプログラ ミング言語における抽象化のトレンドに乗 ったものて、あり , 生まれるべくして出てき たものて、あるといえる。日常生活て、は , 「抽 象的」という形容や , 「抽象論」という呼び名 は , どちらかといえばけなし文句て、ある。 すなわち具体性がないということて、ある。 ところが , プログラミングの世界て、は , パラダイムの抽象化は明白なトレンドて、あ り , 歴史的にも抽象化のレベルは確実に上 ことプログラミ がってきている。これは , 32 C MAGAZINE 1 3 11 ングに関しては , 人間の思考は極めて抽象 度が高いところに位置しており , 言語がそ こに近づこうとしているからだと解釈て、き る。 かってはソフトウェア作成技術の未熟さ もあり , あるいはマシンパワーがプアて、あ ったこともあり , プログラミング言語にお ける抽象度は低かった。その時代には , 人 間が思考レベルをコンピュータ寄りに下げ てやることて、 , 全体としての調和をとって いた。そうて、なければ , 効率よくコンヒ。ュ ータを使うことがて、きなかったからて、ある。 そのころのプログラミングは , マシンレ ベルて、思考て、きるという特殊な能力を持っ , ほんのわずかな人だけが行っていた作業て、 あり , ( 今日のレベルから見れば ) 比較的簡 単なソフトウェアしか作られなかった , もある。そのような状況て、は , とくにそれ て、不自由はなかったのて、ある。 ところが , プログラミングに対する要求 は日増しに高度なものとなり , 必然的にプ ログラマの人口は増えざるを得なくなった。 そして , プログラマ人口が増えるにつれ , 思考レベルをコンヒ。ュータ寄りに下げるの が苦手な人間もプログラミングすることに なる。そこて、 , コンヒ。ュータの側が抽象度 を上げて , 人間に歩み寄る必要が生じたの て、ある。幸いなことに , コンピュータのハ ードウェア性能は飛躍的に向上した。コン ピュータ側が多少の効率低下をきたしても , プログラミングが容易になる方向にもって いくほうが , トータルて、の効率が向上する のは間違いない さて , ひとまず抽象論は終えて : ー ) プ ログラミング言語における抽象度の向上の 歴史を具体的に見ていこう ( Fig. 1 ) 。 ・機械語 第 1 世代のプログラミング言語は , 機械語 てあった。マシンコードを 2 進 , 8 進 , 10 進 , 16 進などの基数て、表した数値を用いて , 直 接コーディングしていたのて、ある。つまり 命令をビットパターンとして扱っていた。 ・アセンプラ しかし , 機械語は , 第 2 世代言語 ( アセン プラ ) の登場て、速やかに置き換えられた。ア センプラて、は , 機械語命令をビットパター ンて、表現するのて、はなく , それらに人間に とって意味のある ( 意味を連想しやすい ) 名 前をつけてコーディングすることにした かっ , 機械語プログラミングて、は直接数値 を指定していたアドレス指定に , やはり人 間にとって意味を持つ記号名を許すように した。これらはいずれも , 必要のない物理 的な実装の情報を捨てる行為て、あり , 実際 にコンピュータが内部て、行っている処理を 抽象化し , 一歩人間に近づけたものだと解 釈て、きる。 ・手続き型言語 ( 非構造化 ) アセンプラは , さらに初期の高水準言語 ( たとえば初めての実用的なコンパイラ言品 て、ある FORTRAN) にとって代わられた。 FORTRAN ( 当時は FORTRAN II とか , F ORTRANIV て、ある ) は , 今日的な視点から 見ると , いくらて、も欠点を指摘て、きる言語 て、はあった。 しかし , それまて、の機械語やアセンプラ によるプログラミングが , 裸の CPU のアー キテクチャ ( レジスタ構成やレジスタ幅 , 命 令セットなどが提供するプログラミングモ デル ) に縛られていたのに対して , それらと は独立に , 抽象的な「 FORTRAN マシン」と いうプログラミングモデルを与えた点は画 期的てある。 こて、もキーワードは , プロ グラミングモデルの抽象化て、ある。 ・構造化言語 さて , 構造化プログラミングが論じられ るようになると ,FORTRAN の goto に依存 する制御構造がやり玉に上がり , 盛んに批 判を浴びた。そこて、広まったのがプロック 構造と , 構造化構文を有する Alg 。 1 系の言語 て、ある。 これらの言語て、は , if-then-else や while な どという構文を導入するとともに , 複数の

る . ア 2 五 一言 0 0 0 富て、あることは大切だろうが , それが仇と なって , C 十十て、はオプジェクト指向パラダ イムが本来持っている単純明快な概念が曖 昧になっている。 本章て、は , C 十十て、簡単な OOP の例を記述 「 C 十十を用いて OOP をしよう」と志した初 し , それと等価なプログラムを C て、実現する 心プログラマは , C 十十の膨大な機能の大海 にはどうすればよいかを考えていく。 に揉まれてキリキリ舞させられ , 「オプジェ なお , ここて、は , OOP の例を示す言語と クト指向とは , なんて難しいものなのだ」と して , C 十十を採用する。 C と対比を行う場 思ってしまう場合が多いらしい。あるいは , 合の対応づけの容易さや , 読者の手元て、 ( 仮 C 十十の機能のホンの一部を見ただけて、 , 「な に目下のところ使えないとしても ) 近い将来 るほどこれがオプジェクト指向か」と変に納 に利用可能になる確率の高さを考慮すると , 得してしまい , 本質的な点を見落としがち C 十十を採用するのが妥当だと判断した。 だという意見もある。 ただし , 誤解されないように断わってお 本誌て、おなじみの松田晋氏の指摘によれ きたいのだが , 例示のための言語として C 十十 ば , 「 cout くく "hello world" : 」と , prin を選んだのは , ほかにより適切な選択肢が tf て、はなく、、 < < クを用いて出力を行うこと なかったという , 消極的な理由が大きい が , すなわちオプジェクト指向なのだと信 OOP がここまて、普及してくる原動力となっ じている人がいるそうて、ある。実際には , たのが C 十十の存在て、あることは否定しな 、、 < くクを使うことが OOP とまったく無関係 い。しかしながら , OOP という純然たるパ だとはいわないが , それは決して本質的な ラダイムを理解するための教材としては , 遺 ことて、はない。第一 この構文は , オプジ 憾ながら C 十十は最適の言語とはいえない ェクト指向機能以外にも C 十十特有の「不純 むしろ , そういった用途には最低の言語て、 な秘技 ( ? ) 」が , てんこ盛りされた結果生まれ あると断言する人すらいるくらいて、ある。 たものて、あるにの点は後て、少し触れる ) 。 C 十十がそのように非難されてしまうの これを見て「これこそがオプジェクト指向だ」 は , 機能が豊富すぎるからて、ある。 C 十十と と信じ込んだりしないて、ほしい C の関係は , 次の等式のようになる。 もう一点 , C 十十に関して注意しておきた いのは , この世に存在するオプジェクト指 + 「諸々の拡張機能」 向機能のすべてを C 十十が持っているわけて、 + 「オプジェクト指向機能」 はないことて、ある。たとえば CLOS (Comm + 「オプジェクト指向機能を実現す on Lisp Object System) て、用いられるメソ るためのつじつま合わせ機能」 ; ッドコンビネーションと呼ばれる概念は , すなわち , C 十十とは , C に対して , オプ C 十十をベースにして紹介していたのて、は決 ジェクト指向機能だけを付加した言語て、は して登場しない OC 十十とはまったく異なる なく , それ以外のたくさんの拡張機能と , 発想のオプジェクト指向機能が存在するの オプジェクト指向機能を付加する上て、避け て、ある。だから , オプジェクト指向機能の て通れない問題を解決するための , つじつ 全貎をきちんと理解したいと望むならば , ま合わせの機能も同時に追加したものなの C 十十だけに縛られずに , もっと視野を広げ て、ある。そして C + + の問題は , 「諸々の拡 てほしい。特定の言語の世界だけを見てい 張」と必要に迫られてつけざるを得なかった たのて、は別段不満に感じていなかった機能 「つじつま合わせ」の機能が , 結果的に が , ほかの言語の仕様を知ったことて、 , 実 「 4 ロロ をたいへん複雑なものにしてしまった , はたいへん不十分なものだったことに気づ にある。実用言語として考えれば機能が豊 くことは少なくない はじめに きだあき - 00P とはソフトウェア構造 に対する思想といってよい。 その思想を学ぶには Sma Ⅱ t a 賑などに代表されるオプジ ェクト指向言語が最適ではあ るが , その本質的な部分であ れば C 言語でも十分学習可能 である。本章では C 言語によ るオプジェクト指向プログラ ミング技法を紹介する。 38 C MAGAZINE 1 3 11

特集℃言語とオプジェクト指向 風」の用語は一切使わないことにしている「オ プジェクト指向言語」もある ( たとえば Ober on ー 2 ) 。それぞれの言語の設計者は , 何らか の主義主張に基づいて , 最適だと信じる用 語を選択しているのだろうが , ューザの側 からみると , 無用の混乱を招いているだけ のような気がする。 それぞれの言語が提供している機能が微 妙に違うから , 名前が違うのだという議論 も成り立つのかもしれないが , 用語の乱立 は今が黎明期て、あることの証て、 , いずれこ の混沌が ( もう少し ) 解消される時代がくる のてはないかと思う。 それて、は , オプジェクト指向のメリット はどこにあるのだろうか。筆者は , 本質的 には以下に示す 2 点に集約されると考えてい プログラムの保守性が高まる プログラムの再利用性が高まる そして , この結果として , プログラムの 生産性が向上するというのが最大のメリッ トて、あろう。これらはすべて述べてきた OO P の特徴が相まって引き出されるメリットて、 ある。 まず , OOP て、は , 実世界を比較的容易に ソフトウェア上に写像て、きる。これが保守 性を高めると考えている。現実界て、は , 具 体的な「モノ」が複数独立に存在し , それら が相互に情報 ( メッセージ ) を交換しあって 世の中が回っているのて、ある。 オプジェクト指向て、はソフトウェア上て、 これらのモデルを作り上げるのが容易て、あ る。その結果 , 現実界の構造に忠実なソフ トウェアがて、きあがる ( ただし , そのために は , ソフトウェアシステムの分析や設計も オプジェクト指向を利用する必要がある。 言語だけをオプジェクト指向にしても意味 はない ) 。 非オプジェクト指向のソフトウェアは , オプジェクト指向の ~ メリット 機能に着目し , それを階層的に分割してい くことて、設計されるのが普通て、ある。その ため , 設計時点て、要求されていた機能を実 現することには注意を集中させるが , 現実 界の構造との整合に関してはとくに意識し ことが少なくない。その結果 , 内部構 造が現実界の構造とは似ても似つかぬもの になってしまうことがある。そのような場 合に , 後日「ちょっとした要求仕様変更」が 行われると , 「ソフトウェアの構造上」その ような機能を提供するのは非常に困難て、あ るということもあり得る。保守上好ましく ないのはいうまて、もない 再利用性が高まる理由のひとつは , オプ ジェクトがカプセル化された実体て、あり , すべてがそこに含まれていて , かっ外部と のインタフェイスは明白に規定されている こまて、て、あれば抽象 からて、ある。だが , データ型と同じて、ある。オプジェクト指向 の場合には , さらに継承という形て、の再利 用が可能てある。これは大きいメリットて、 ある。 さらにもうひとつ指摘しておきたいのは , 動的結合て、あれば , あるライプラリを , 再 コンパイルなして、 , ューザが新しく作りだ した新規なデ、一タ型に対応させることがて、 きるということて、ある。強く型づけされた 抽象データ型言語の場合には , このような ことは不可能て、ある。なぜならば , 特定の データ型に適用可能な手続きはあらかじめ 定められていて , それはコンパイル時に決 定されるからて、ある。将来定義されるて、あ ろう未知のデータ型に対する , 将来定義さ れるて、あろう未知の処理を呼び出すという 機能は , 動的結合を利用して , 初めて可能 になる ( 手続き型変数とか , 関数へのポイ ンタといった機能を使えば可能だという反 論が聞こえてきそうだが , それらは一種の 動的結合なのだから , 可能なのは当然て、あ る ) 。 C て、 OOP を試みるときにも , これらのメリ ットを踏まえていなければ意味がない。あ るオプジェクト指向機能が , C て、は簡単には 実現て、きないものだったとしよう。たとえ ば , 多重継承機能というのは C て、直接書き下 また , カプセル化 ろすのはかなり難しい をきちんと実現しようとするならば , 情報 隠蔽が必要て、ある。すなわち , アクセス権 のない外部の第三者が直接オプジェクトの 内部状態を変更することを禁じる必要があ る。 しかし , アクセスコントロールの機能は , オプジェクトが直接 C の構造体を利用して記 述されているかぎり , 逆立ちしても実現は て、きない ( ただし , 情報隠蔽が本質的に「オ プジェクト指向機能」て、あるのかどうかにつ いては , 議論の余地がある ) 。 そのような場合に , その機能を実現する ために非常に複雑なコード構造にしたり , プログラミングやコーディングの規約に大 幅な制限を加えなければならないのて、あれ ば , そんな無理な工夫はしないほうがよい もともと C はオプジェクト指向言語て、はな い。て、きることとてきないことがある。仮 に苦心惨憺してその機能を実現したとして も , どこかにしわ寄せがくる。保守性や生 産性が低下するか , 安全性が著しく損なわ れるかて、ある。そういうときには , 何のた めにオプジェクト指向を採用するのかを冷 静に検討しなおしてほしい どうしても特定のオプジェクト機能が必 要て、 , それがなければプログラムが完成し ないというような事態が生じたとしても ( そ ういう事態が生じるかどうかは , かなり疑 問だと思う ) , そのプログラムの中て、その機 能を実現しようと悪戦苦闘するのは避けた ほうがいい。むしろその場合には , ツール ( 言語 ) の選択を再考すべきて、ある。 オプジェクト指向言語が存在するのは , やはりそれだけの意義があるからて、ある。 ひとつの言語に惚れ込んて , 何て、もそれて、 済ませようとすることを一概に否定するこ とはてきないが , やはり物事には限界があ ることを忘れてはならない。そしてその限 特集 C 言語とオプジェクト指向 ログラミングパラダイムなのて、ある。 界を破るのが新しい言語てあり , 新しいプ 37

1993 年 11 月 1 日発行 ( 毎月 1 回 1 日発行 ) 第 5 巻第 11 号通巻 50 号 1990 年 2 月 2 日第 3 種郵便物認可 提携・ LA 一誌 / 監修・石田晴久 C 言語技術情報誌・ C マカシン 1993 NOV. V . 5 No. 980yen 特集 : ・ , O 一言語とオプジェクト指向 新連載【 (D>< ーープログラミング 提携記事 >Substance StyIe:GUIDesign and Cu ぎ「ツ一 O 言語雑学講座マ TextE 実践アルゴリズム戦略マ逐次添加法 / MS 占 OS 非公開情報詳説マ DOS 5.0 公開機能③ & OOw / > ゲーム大作戦効果音② / < 級型 O 十十入門マクフスの <mo O 言語プログラミングレッスン >LUOLL まで繰り返せ LONXO ・オプジ = クト指向プログラミング環境「 OPEV 」 ・ O 言語ライプラリ「 TxP 「 om ℃ t 」他・関連マクロ集 特別付録 . o コンパイラ「 LS 一 986 く e 「 . 3.300 試食版」