“オプジェクト指向”を こう考えてみよう どが「もの」であり , 購入する・包装して渡 オプジェクト指向では , 機能よりも現実 いいます。 世界に存在する「もの ( オプジェクト ) 」に注 すが「振る舞い」です。また「もの」には「属 オプジェクト指向プログラミングでは , 目します。たとえば , 人は「もの」です。犬 性」もあります。「あなた」には所持金とい 現実世界をコンピュータ内部に写像し , や猫 , 車や建物も「もの」です。また形がな う属性があり , 「本」には所有者という属性 「もの」を「オプジェクト」と表現することで いもの , たとえば日付とか権利なども「も が , 「レジ」には売り上げという属性があり プログラムを作ります。このときのオプジ の」ととらえることがあります。 ます。振る舞いをすることによって , 今の ェクトは , 属性に対応するデータ構造と , 現実世界では複数の「もの」が影響を及ぼ 例でいえば本を買うことによって , 属性は 振る舞いを 1 つにまとめたものです。同じ し合いながら存在しています。本を買うこ 変化していきます。 種類の属性と振る舞いを持つオプジェクト とを考えてみましよう (Fig. 1 ) 。本屋であ 「もの」は 1 つ 1 つが孤立しているわけでは は「クラス」にまとめられます。通常オプジ なたが本を選び出し , レジに持っていって , なく , ある集団にまとめることができます。 ェクトは何らかの「クラス」に属しており , そこで購入すると , レジの人が本を包装し あなたでも私でも隣のおじさんでも , 本屋 その「インスタンス ( 実例 ) 」として作り出さ て渡します。このように「もの」は「振る舞 に行けば本を売ってくれます。本屋の立場 れます。 い」 ( 別の視点から見ると「機能」 ) を持ちま から見ればすべて「お客さん」とまとめるこ オプジェクトの属性 ( データ ) は , 原則と す。今の例でいうと , あなた・本・レジな とができます。 このまとまりを「クラス」と して外部から直接操作することはありませ ん (Fig. 2 ) 。オプジェクトに対してメッセ Fig. 1 現実の世界とプログラム内部の世界 ージを送ると , そのオプジェクトは何らか の振る舞いをします。属性は振る舞いの結 果として変化します。またオプジェクトは 数値計算や入出力などの振る舞いもします。 さらに別のオプジェクトにメッセージを送 ることもあるでしよう。このように , オプ ジェクト指向のプログラムは , オプジェク ト同士でメッセージをやりとりすることに よって機能します。 オプジェクト指向プログラミングには , 以下の重要な概念があります。 ・抽象化 ・カプセルイヒ ・継承 ・ポリモーフィズム これらは相互に関連して , 全体でオプジ ェクト指向手法を構成します。 「抽象化」というのは , そのオプジェクト が具体的に何であるかや , どういう内部構 造になっているかを気にしなくてもいいと いうことです [ 注 1 ] 。外部からは , どのような データを保持しているかと , どのメッセー ジを受け取ることができるかさえわかれば いいとするのです。これは通常 , オプジェ クトをクラスにまとめることによって実現 されます。詳細を考えることを省略でき , 複雑さの削減をもたらします。 「カプセル化」とは , オプジェクトの内部 現実の世界 オブジェクト オブジェクト メッセージ オブジェクト プログラム内部の世界 特集プログラミング入門 " オブジェクト指向 " を考えてみよう 53

“オプジェクト指向”を こう考えてみよう Fig. 5 従来の方法とオブジェクト指向の方法 という人はいません。その「オプジェクト」 ( 現実世界のすべてのものがオプジェクト だという話はひとまず置いて , プログラム 上のオプジェクト ) とは , データ構造と振 る舞い ( 機能 ) が一緒になったものというこ とも一般に承認されるでしよう。オプジェ クトは , メッセージを受け取って振る舞い を実行し , 時にはほかのオプジェクトにメ ッセージを送ります。そのようにしてプロ グラムが動きます。 さてここで , オプジェクト指向以前の構 造化手法を見てみましよう。 C 言語で作成 されたプログラムを想定してください。構 造化手法では , 実現したい機能がまず先に あり , それをサプルーチンや関数に分割す ることによって実現していきます。機能の 実現に関しては上位の関数が責任を持って いて , 下位の関数を完全に制御することが 必要でした。 オプジェクト指向では実現したい機能が あっても , 自分で実行できません。なにし ろ機能はオプジェクトの中にまとめられて いるのですから。できることは , その機能 を担当するオプジェクトにメッセージを送 り , 信頼して任せるだけです。 さて , 「オプジェクト」なんていうあちら 側の存在を , ことによっては反対しそうな ものを「指向」するとはどういうことでしょ うか。「オプジェクト」をその原義から「自 分でないもの」ととらえて , 「オプジェクト 指向」を「自分でないものを主要なものとみ なす」と考えると , それはまさにオプジェ クト指向のプログラムで起こっていること を表しています。「自分でないものを主要 なものとみなす」は逆からいうと「自分を抑 える」ことになります。 プログラム内部のやりとりで , メッセー ジを受け取るオプジェクトは「客体」であり 「対象」です。しかし , メッセージを発する 「主体」は , 発するのみであとは何もやらず , 「客体」を主要なものとみなし , そちらに機 能の責任を任せます ( Fig. 5 ) 。「客体」であ るオプジェクトが「主体」となって , ほかの 主体 責任 主体 従来の方法 関数 ( サブルーチン ) 客体 呼び出し オプジェクト指向の方法 オブジェクト オプジェクトにメッセージを発することが あるかもしれませんが , そのときもやはり , 相手に機能を任せています。つまり , 「オ プジェクト指向」とは , プログラムで行い たい操作の実現において , ある主体がある 客体 : Object を主要なものとみなす , 「任せ る」ことです。オプジェクト指向とは任せ ることなのです。 そう考えると , オプジェクト指向の諸特 徴が見えてきます。任せるためにはそのオ プジェクトができることは何かを把握しな ければならないので , 「クラス」を使います。 「抽象化」によって , 受け取るメッセージの 特集プログラミング入門 " オブジェクト指向 " を考えてみよう 5 / 一覧 ( インタフェイス ) を公開します。また , 機能を任された以上は内部構造の公開は不 必要であり , 有害でもあるので「カプセル 化」してオプジェクトの内部を隠蔽します。 さらに , ある機能を任されたからには , 具 体的な動作はオプジェクトごとに異なって いてもよく , これが「ポリモーフィズム」と なり , それを実現する機構が「継承」です。 客体 責任 お任せ手法 もう一度「オプジェクト指向」という言葉 メッセージ

Standard スレッドロックの本質的な規範は , ロック操作をクラス内部 ・標準 C + + ライブラリはスレッドロックの必要性を最小にす にカプセル化することだ。ロックのコードをコンストラクタに べきである コードをスレッドセーフにする最上の方法は , マルチスレッ 置き , ロック解除のコードをデストラクタに置く。クリティカ ルセクションは次のように複文のような形式で記述することに ド処理と無関係にすることである。たとえば , sqrt のような純 粋関数は , 何も心配する必要がない。この関数はすべての仕事 なる。 {-Lockit ユ oc 新 / / このプロックをロックする をローカルメモリで行う。ローカルメモリはスレッドごとに固 有である。このような関数で問題を引き起こそうとするなら , 〃クリティカルセクション 回り道をしなければならない。 Silicon Graphics の人たちは , Hewlett-Packard で始まった素晴 問題を引き起こす方法の 1 つは , クラスや関数の中で書き込 らしい伝統を継承し , 無料で利用可能なプロダクトとして STL み可能な静的オプジェクトを管理することである。標準 C ライ の拡張を続けている。彼らは素晴らしく実用的な , 訂 L コンテ プラリには , そういうどうしようもない関数がいくつかある。 ナのためのスレッドセーフに関する定義を次のように提示して たとえば , st れ。 k の場合 , 呼び出しの間の状態情報を格納してい る。少なくとも若干の保護コードを追加しない限りは , 2 つ以上 いる。 ・コンテナオブジェクトは 2 つ以上のスレッドから安全に読 のスレッドで s ok をうまく利用するようにサポートすること むことができる ( コンテナは保護されない mutab 厄オブジェ はかなり難しい。標準 C + + ライプラリでは , このような書き込 クトを持たない ) み可能な静的領域の共有を必要としないようにしている。優良 ・同じ型の別のオブジェクトがほかのスレッドから書き込ま な処理系は , 本当に必要でない限り , 書き込み可能な静的領域 れている場合でも , コンテナオブジェクトは 1 つのスレッド を加えることはない。 から安全に読むことができる ( コンテナクラスは保護され もう 1 つ , さらに微妙な方法は , mu ね ble なメンバオプジェク ない共用可能静的オブジェクトを持たない ) トを使うことで複数スレッド処理の問題に対応することだ。あ ・ほかのスレッドから読み出し , 書き込みされている場合 るオプジェクトの中身を読み出しているだけだと思っている場 コンテナオブジェクトは 1 つのオブジェクトから安全に書 合でも , 実際はその内部状態を変更している場合がある。たと き込むことはできない ( 明らかな衝突の回避はプログラマ えば , 見かけは読み出しでも , キャッシュの更新を伴っている の責任である ) 場合がある。 単純にいえば , これらの規則は , 複数スレッドプログラムで , 2 つのスレッドが何も考えずに共有しているオプジェクトを 標準 C + + ライプラリ ( 少なくとも L 部分 ) が驚かせるような挙 読み出そうとする場合 , 一般には保護を必要としない安全な操 動を示さないことを約束している。同様に , 下手に助け舟を出 作であるが , 見えない書き込みにより干渉が生じ , 読み込みの してかえって迷惑をかけてもいけないので , プログラマを助け 際にフリーズしたり , オプジェクトが一貫性のない状態に置か れたりする可能性がある。良質な実装では必要なところでだけ , るために自分のやり方から逸れることもない。 mutable なメンバオプジェクトを使い , ロックされたアクセスを 重要な例として , Microsoft から販売されている Visual C + + は 完全にスレッドセーフではない。 Microso れはこの既知の問題を 提供することで , 読み込みを外部から見たままの安全な状態に 修正するためにいくらか努力しているが , これは V5.0 , V6.0 の する。 どちらも完全にスレッドセーフではない。他方で , 修正の完全 ・すべてのロックはカプセル化しなければならない 例外は生じるものだ ( バンパーステッカーによく書いてある なセットを ことわざだが ) クリティカルセクションの中でさえ例外が生じ http : //稲喞.dinkumware.com/vc-fixes.h し る。例外が生したときに , もともやりたくないことは 0 、 , ク から入手することができる。 を永久にそのままにしておくことだ。だから , そうならないた この変更により , V1sual C + + は , 少なくとも Silicon Graphics めに例外が投げられた場合でも確実に実行される場所にロック の人たちが定義するのと同程度には本当にスレッドセーフにな を解除するためのコードを置いておくことだ。その場所とは , る。 どなたでも絶対にご存じの場所 , ローカルオプジェクトのデス あなたが使っているコンパイラの STL がスレッドセーフかど うかについては , それを書いた人に尋ねてみてほしい。 トラクタの中である。 Standard C/C + +

“オプジェクト指向生、 こう考れみよう 毛呂宗夫 C + + などの入門書には , 「オブジェクト指向」という言葉がよく出て きます。でも , それはそもそもどういうものか , と聞かれたときに 答えられるほど理解している人は少ないでしよう。ここでは , プロ グラミング言語という側面からだけでは理解しにくいこの言葉につ いて , 1 つの解説をしてみようと思います。 ています。もうすっかりオプジェクト指向 オプジェクト指向 は定着しました。 ・・・本当でしようか ? との出会い 人と話をするとき , 「オプジェクト指向 がね・・・・・・」というと , なんとなくうしろめ 私たちがオプジェクト指向という言葉を たい気にはなりませんか ? たとえるなら , 聞いたのはいつだったでしようか 歓談中に歴史の話になり , 学校で習ったは オプジェクト指向は , 1965 年に開発され ずだけど詳しくは覚えていないので , あま 以下の話を進めるには , とりあえずオプ たシミュレーション用言語 Simula から始ま り深入りしたくない , というような。「オ ジェクト指向について知ってもらわなけれ りました。ということはもう 30 年以上の歴 フシェクト指向が・・・・・・」といって , もしも ばなりません。 史があります。 「あなたの言うオプジェクト指向とは何を ーロに「オプジェクト指向」といっても , しかし , この言葉が一般的になったのは 意味するのですか。明確に答えてください」 説明する人によってその内容は多種多様で そう昔ではありません。多くの人がそうで と詰問されたらどうしようという不安が頭 す。オプジェクト指向コミュニティには多 あるように , 私も C + + 言語の解説の中でオ をかすめませんか ? まあ詰問する人はい くの教祖がいて , 言っていることが微妙に プジェクト指向という言葉を初めて目にし ないでしようけど。 違い , 同じことを言っているようにみえて ました。一般に C + + のコンパイラが出回る 「オプジェクト指向とか何とか , そういう も言葉の意味がずれていたりします。 のが 90 年代に入ってからなので , まだ 10 年 ややこしい話は御免こうむる」と言えたな そこで細かいことはさておき , 平均的な , 程度しかたってません。 らどんなにすっきりするでしよう。ですが , いわゆる「オプジェクト指向の説明」をしま それほど昔ではありませんが , この言葉 それでは技術の進歩についていけないやっ しよう。以下はごく穏当な解説のつもりで と出会ったときの感想はあまりよく覚えて だと思われそうで , 言えないのではありま す。 いません。たぶん「ふうん。世の中には小 せんか ? オブジェクト指向とは 誰もが知っているのに , 詳しい説明がで 難しいことを考える人がいるなあ」と , 気 きなくて , 何となく恐れられている・・ オプジェクト指向とは , サプルーチンで にとめなかったと思います。 それから「オプジェクト指向」の領域はず れではまるでオプジェクト指向は妖怪みた はなくオプジェクトによってプログラムを いぶん拡大してきました。本屋に行けばオ いです。しかし , オプジェクト指向といっ 形造る手法です。 プジェクト指向の解説書が棚を 2 つ 3 つ占め ても , もともとはコンピュータのプログラ 従来の構造化プログラミングでは , まず ており , プログラミングの世界ではオプジ ムを開発する手法の 1 つにすぎません。怖 最初に実現したい機能を決め , それを小さ ェクト指向をサポートした言語でなければ かったりわけのわからないものだったりす な機能に分割することでプログラムを構成 時代遅れのように言われます。それに , 現 るはずがありません。これはたぶん , いく しました。プログラムを構成する単位はサ 在販売されている C 言語のコンパイラはほ つかの誤解が霧のように立ちこめて , オプ プルーチン一一℃言語では関数ーーでした。 とんど C + + のコンパイラでもあります。そ ジェクト指向の姿をばやけさせ , 妖怪みた 一方 , サプルーチンや関数が利用するデー のほか , Object PascaI , Smalltalk , Java な いに見せているからではないでしようか タ構造は , 機能の分割とは別の基準で設計 ど , 多数のオプジェクト指向言語が使われ こでは , そのうちの 1 つの誤解を解く されていました。 ことを試みます。少しはオプジェクト指向 の顔が見えやすくなるかもしれません。 オブジ土クト指向 の平均値 52 C MAGAZINE 2001 4

00 フログラミング入門 を見てみましよう。日本人にはこの言葉は ればいいわけです。 上記の ER 手法や , そのほか多くのプログラ なじみがなく , 聞いたときにイメージの湧 ミング開発手法が「オプジェクト指向」の中 シミュレーションと こは 1 つ「お任せ手 に流れ込んでいます。わかりにくさはその きようがありません。 オブジェクト指向 法」といってみてはどうでしようか。「お任 せいでもあります。 せ手法プログラミング」「お任せ手法分析・ 現在のオプジェクト指向は全体としてか 設計」。威厳はないですが , 親しみやすい オプジェクト指向はシミュレーションの なり複雑であり , 専門用語を使ってしか説 分野から生まれました。考えてみれば , シ と思います。 明できない面もあります。「継承」や「クラ ただ , これは本稿だけの言葉なので , 外 ミュレーションこそ「お任せ手法」そのもの ス」がないオプジェクト指向もありえます です。全体として制御せずに , 要素間の作 部の人に言うときには注意してください。 が , しかし自動車にヘッドライトやノヾンパ 取引先に「当社ではオプジェクト指向を活 用に任せているのですから。さらに , コン ーがなかったらちょっと困るというように 用してプログラム開発を行っております」 ピュータで行う仕事の多くの部分は , シミ 根元的に必須ではないにしても無視するこ ュレーション的な性質を持ちます。たとえ といって「おお , よくわからないけど難解 とはできません。 で高級そうだ。人月単価を上げてあげよう」 ば在庫管理システムなんかも , 現実の在庫 いわゆる「オプジェクト指向」については となるところが , 「当社ではお任せ手法を をコンビュータ内に写像し , その動きをな さまざまな本が出版されているので , 詳し 活用してプログラム開発を行っております」 ぞるものなので , 多少強引ですが , シミュ いことはそちらを見てください。ただその といって「ううむ。なんだかいいかげんで レーションに似たものといえます。 根底に , 「任せること」と「シミュレーショ 頼りなさそうだな。契約を破棄しよう」と オプジェクト指向は現在でもシミュレー ン」を仮定すると全体像がとらえやすく , ま ションの概念を引きずっています。ただ なっても責任は持てません。 た理解しやすくなると思います。 このシミュレーションというパラダイム ( 考 だけど「オプジェクト指向はお任せ手法 最近「エージェント指向」という言葉を聞 である」と考えるといくらかご利益があり え方の枠組 ) が何にでも適用できると思う くようになってきました。意味が混乱して ます。オプジェクト指向プログラム言語 , ところにもう 1 つの誤解があると思うので いる面もありますが , これもオプジェクト たとえば Java などを使って開発していると , すが , それはここでは触れないでおきます。 に判断力を持たせたような「エージェント」 Java の場合メッセージは public オプジェクト指向はプログラミングだけ というモジュールに機能を任せるという理 メソッド なメソッドとして実装されます一一 - で , 戻 にとどまらず , ER モデル分析 ( システムを 解でいいでしよう。オプジェクト指向と同 り値がないものをよく使います。これはオ 「実体」と「関連」ととらえて分析する手法 ) じレベルにおいて対立するものではないと の影響を受け , 「オプジェクト指向分析」と プジェクト指向としては当然のことですが 思います。 機能分割による構造化手法に慣れた人に いう分野が発展しました。簡単にいうと , 現実世界をオプジェクトに置き換えて分析 は , 気持ち悪く感じるはずです。メソッド する , つまり現実世界をオプジェクトによ とかメッセージとかいっても , 形態として は C 言語の関数と同じなので , それを連想 ってシミュレートする手法です。これは今 ではプログラムの分野だけでなく , 企業・ してしまいます。 C 言語の標準関数では返 コンピュータなどをいじる人は , どちら り値がないのはむしろ例外であり , printf() 組織・社会構造の分析にも適用しようとい かといえば神経質で , 細かいことまで自分 関数なんかでもほとんど使われないのに返 う動きが出ています。 でやりたがる性格だと思います。統計をと り値として出力文字数を返してきます。メ ったわけではありませんが・・・ 現在の ソッドも , 返り値として , せめて実行の状 先に , 「度量を大きく持って」と書きまし オブジェクト指向 況を報告しないとまずいのではないか , な た。オプジェクトに任せるということは , し どと思ってしまいます。 ばしばこの性質が要求されます。ある機能 しかし「お任せ手法」と考えれば悩まなく しかし , 「オプジェクト指向」が単なるお について「自分で制御したい」という欲求は , て済みます。任せた以上は細かいことは考 任せ手法であるとか , シミュレーション用 誰でも持つものだと思います。しかしそれ えず , 度量を大きく持ってオプジェクトに の手法だと考えても , それですべてを表し をやってはなりません。オプジェクトに任 任せます。もし向こうでどうにもならない きれるものではありません。オプジェクト せたのだから , 任せた以上は信じるという ような非常事態が起きたら , 「例外」という 指向は多くの人が洗練させてきたもので , 態度が肝心です。 SOS を投げてくるから , そのとき対処をす いろいろ特別な意味が付与されています。 会社組織にたとえてみましよう。資料の がまんがだいじ 58 C MAGAZINE 2 1 4

00 フログラミング入門 は外部に見せずに隠すことができるという ことです。外部からの勝手な使用や不正な 使用をさえぎることができます。 「継承」というのは , クラスを階層的に組 織できるということです。「猫」と「犬」とい うクラスがあったとします。これらはどち らも動物であり , 「食べる」とか「動く」など , どんな動物にも共通する振る舞いを持って います。そこで , これらの上位のクラスと して「動物」クラスを作り , 「猫」や「犬」クラ スはそこから「継承」させることにします。 これによって , 共通する振る舞いを 1 つに でき , あとは「顔を洗う」「舌をハアハアす る」など , サプクラスで特有のことだけを 記述すればよいのです。これによりコード 記述は大幅に節約できます。 最後に「ポリモーフィズム」です。「犬」と 「猫」の「鵈く」という機能を考えてみましょ う。犬はワンと鳴き , 猫はニャーと鳴きま す。「鵈く」という機能は同じでも , 実際の 行動は異なります。このことをポリモーフ ィズム ( 多相性 ) といいます。 オプジェクト指向プログラミング言語は これらの概念をサポートする言語です。抽 象化・カプセル化によってモジュール性が 向上し , 継承・ポリモーフィズムによって 拡張しやすくなっているので , プログラム の再利用を促進します。その結果として高 い生産性をもたらします。 [ 注 1 ] 抽象化の意味するものは人によって大きく 異なります。ある人はクラスによる抽象化 を想定し , 別の人は継承による抽象化を想 定し , また別の人は現実世界の「もの」を 「オプジェクト」に写像することを抽象化だ と考えています。抽象化が重要な性質だと いうことでは一致するのですが。 一般的な解説での理解度 さて , 上の文章を読んで , オプジェクト 指向が何であるかおわかりいただけたでし ようか。 「完全にわかった」というのならたいへん けっこうですが , おそらくそうではないと 思います。「わかったような , わからない ような・・・・・」という人が大部分でしよう。 54 C MAGAZINE 2g1 4 ァータは外部から直接操作できない オブジェクト 振る舞い・機能 データ の意味 どうでしよう。生まれてから一度もこの言 さて , 「オプジェクト指向」という言葉は 体的な内容まで想像できるはずです。 教育とか , ドライノヾへの広報活動とか , 具 ぐに理解できます。さらに , 学童への安全 通の , 安全のための , 運動なのだな」とす を聞いたことがない人がいたとしても , 「交 しよう。もし生まれてから一度もこの言葉 「交通安全運動」という言葉を考えてみま まりにも不親切すぎます。 ます。「オプジェクト指向」という言葉があ 大の問題は「オプジェクト指向」自体にあり わからないのはある意味で当然です。最 「オブジェクト指向」 終わってしまうようです。 が , それでも結局 , よくわからないままに に上手に解説をしている本も多くあります んだことがあるでしよう。これよりはるか 上のような解説は , 誰でも 1 回や 2 回は読 です。 「わかったような , わからないような・・・・」 いで「わかりました」と答えますが , 本音は 接「わかりましたか ? 」と聞かれればっきあ もし筆者自身がこれを読んだとしても , 直 メッセージ で , 原語は "Object-Oriented" です。これは 「オプジェクト指向」という言葉は翻訳語 うか。少し調べてみたいと思います。 か担っている意味があるのではないでしよ わかりにくい「オプジェクト指向」でも , 何 なぜ名付けられたのでしようか。これほど しかし , ないほうがいいような名前なら , んか。 とすると , かえってわかりやすく感じませ とは , データ構造と振る舞いをまとめ・・・・・・」 開発手法として A 手法が有力である。 A 手法 ったのではないでしようか。「プログラムの 向」ではなく「 A 手法」とでもしたほうがよか ないはずです。これなら「オプジェクト指 日本人の 9 割以上は何のイメージも浮かば はしばしば使われますが , そうでなければ 「オプジェクト」は , コンピュータの世界で 段はまるでなじみのない言葉です。とくに だいたい「オプジェクト」も「指向」も , 普 は絶対に出てこないでしよう。 って階層構造をなし・・・・・・」という内容まで れはクラスに分類され , クラスは継承によ 舞いをまとめたものがオプジェクトで , そ 知っていたとしても , 「データ構造と振る れます。それがプログラムの開発手法だと 意味するか , まるで見当がつかないと思わ 葉を聞いたことがない人にとっては , 何を

00 フログラミング入門 他面では行為の対象ともなります。 さらに , これら Object の意味にはある共 通点があり , それはやはり「向かって投げ られたもの」という原義と関係があります。 「向かって投げられた」というからには投げ られた人 , あるいは物があるわけです。そ れは「わたし」であったり「彼」であったり , とにかく何らかの主体となる存在 , つまり 、 Subject" です。 、 Subject" という言葉も , いろんな意味を 持っています。辞書には「主題・科目・主 語・主体・家来」あるいは「服従させる」な どの意味が載っています。これは「下に ( su b ) + 投げる」が語源です。「主題」と「服従さ せる」ではずいぶん距離がありますが , 「み ずからのコントロール下に置く , または置 いたもの」と考えると理解できるでしよう。 ℃ bject" は "Subject" の影と考えられま す。 " Subject " への反対意見であり , "Subje ct " の行動の障害物であり , 、 Subject" の感 覚するもの , 行為するもの , つまり "Subjec t " の向かう目標です。一言でいえば , ℃ bje ct" は「あちら側」を , "Subject" は「こちら 側」を代表しています。 オブジェクトは「もの」ではない ところで , 日本語の「もの」という言葉を 考えてみましよう。「もの」といえば普通私 たちは , 「何か『物質』があるんだな」と考え ます。物質に主体の感覚作用が働くかどう かは問題にしていません。この点 , Object が主体の存在を前提にしているのと異なり ます。 さらに , 意識のうえでも違っています。 日本語で「ものにする」とか「ものになる」と いう成句があります。たとえば「彼女をも のにした」といえば , 相手の女性を恋人に したという意味であり , こちら側に引き入 れたということになります。また「仕事が なんとかものになった」といえば , 仕事が こちらの希望を満たしたということです。 日本語でも「ものともせず」などと障害物と してとらえる用例もありますが , 全体とし 56 C MAGAZINE 2001 4 ては「もの」は , こちら側であり , 気安いも のであり , ものがあってうれしいな , とい う感覚を持ちます。 一方 , 英語の Object は , 前述のとおり 「あちら側」を代表するものです。それが単 に「物体」を意味しているとしても , 主体は それに対し , 少なくとも認識をしなければ ならないのです。さらに動詞として「反対 する」という意味もあり , 気安いものでは ありません。英語国民が、 Object " というと き , いちいち意識にはのばらないにしても , 少し緊張するはずです。 つまり「もの」と " Object " は , 現象的には 同じものを指すかもしれないけれど , 意識 の方向としてはまるで逆なのです ( Fig. 4 ) 。 厳密にいえば , 外国語のどんな単語もほ かの言葉で置き換えることはできません。 Fig. 4 ℃ bject" と「もの」 物 もの Object しかし , 、 Object" を「もの」というとき , ズ レがかなり大きいように感じます。ではこ れを何と訳したらよいかですが , どうも日 本語にはびったりの言葉がないようです。 強いていえば「あちら」とか「向こう」とか 「相手」というと人という意味が強すぎます し。といっても「相物」なんて言葉はありま せんが。 再び「オブジェクト指向」の意味 「オプジェクト指向」に戻りましよう。 「オプジェクト指向」 = Object-Oriented" は , 「 Object を主要なものとみなす」 , つまり「何 らかの対象となる存在を主要なものとみな す」という意味と考えられます。それは具 体的にどういうことでしようか。 オプジェクト指向の本質が何かというこ とについては , 統一見解がありません。オ プジェクト指向とは , プログラムのモジュ ール性を高める ( 複数の部分に分割して , 部分内の結合を強く , 部分外の結合を弱く する ) ものという見方があります。しかし 構造化手法でもモジュール性を高めること は推奨されていたので , 独自の手法とはい えません。カプセル化による情報隠蔽を重 視する立場もありますが , これも上記と同 様ですし , それに純粋なオプジェクト指向 言語といわれる Smalltalk でも情報隠蔽の機 能はあまり強力ではありません。「継承が なければオプジェクト指向とはいえない」 という意見がある一方 , 「継承は単に便利 のためのサービスだ」という意見もありま す。クラスを中心に据える人がいる一方で , クラスがなくてもオプジェクト指向プログ ラミングは可能だという立場もあります。 もっとも穏健な意見は「オプジェクト指向 とは何か 1 つの手法ではなく , これらの組 み合わせによって相乗効果をもたらすもの だ」というものです。 なんだかばらばらですが , 共通点を探っ てみましよう。とにかく , 何がなくても「オ プジェクト」は必要です。「オプジェクトが なくてもオプジェクト指向は可能だ」など

、。ーコラム 特異メソッドと特異クラス Ruby プログラミングにおいては , ちっとも重要ではないのです Fig. A オプジェクトと特異クラスの関係 ( object ℃より抜粋 ) が , 特異メソッドの実現は特異クラスを用いて行われます。 Ruby の オブジェクトは , そのオブジェクトだけをインスタンスとして持つ * Ruby's CIass Hierarchy Chart メタなクラスに属しています。このメタなクラスを特異クラスとい います。 Ruby の構文においては「 class < く」で始まる特異クラス定義 における self としてのみ , その特別なクラスにアクセスすることが できます。 ListA の実験では , 特異クラス定義における se けがそのオ ブジェクトの通常の意味でのクラスと異なることを示しています。 特異メソッドはこの特異クラスへのメソッドの追加にほかなりま せん。この関係は Ruby でプログラミングをするときは知らなくて OtherClass-->(OtherClass) もかまいませんが , 特別なオブジェクトを定数として持つような拡 張ライブラリを作る場合は自分が何をやっているのかわかるので知 っておいたほうがよいでしよう。 Ruby が提供する C の A 円である rb define—singleton_method() は , まさにメソッドを特異クラスに追加 十 AII metaclasses are instances Of the class 、 Class するものです。その定義は class. c にあります。 ※カッコ付きのクラス名は特異クラス ちなみに Ruby のソースコードの 1 つ object. c には , この関係を表 ※横向きの矢印は is ー a ? 関係 すたいへん興味深い図が含まれています ( Fig. A ) 。 ※上向きの矢印は継承関係 特異クラスへのアクセス (singletonclass. 「 b) Copyright ⑥ 1993-2000 Yukihiro Matsumoto copy 「 ight ◎ 2000 NetWO 「 k Applied Communication LabO 「 atory,lnc. cl ass Object Copyright ⑥ 2000 旧f0 「 mation-technology promotion Agency. Japan def singleton—class class くく se げ # この self はレシーバ # この self は特異クラス se げ -->(Object) Object- -->(Class) Class- Str = "a".singleton—class p [Str, string, str. eql?(string)) # っ [String, String, falsel いなければどういうマズいことがあるかを のは , オプジェクト発見のためのカタログ 観点はなかなか思い付きませんが , Ruby の です。オプジェクト指向プログラミングに スレッド機構を使う可能性がある場合は対 g. 2 に示します。ここでいう「スレッドセー おいてもっとも難しい問題であるクラスの フでない」とは List4 で 7 行目と 12 行目をなく 処する必要があります。 Ruby でスレッドセ 設計 , いい替えれば何がオプジェクトかと した場合です。 ーフにするのはたいしてめんどうでもない いう問題に対し , すでに有用であることが ふと思ったのですが , Singleton のインス ので日ごろから気をつけたいものです。 知られた多くのクラス構成をデザインパタ タンス生成はⅲ clude のときに行ったほうが 8 行目で@__instance__ にインスタンスが ーンとして Gamma らがまとめました [GHJV] 排他制御の機会が少ないので効率がよいか まだ登録されていないか調べます。もし登 ある程度大規模なソフトウェアを開発する もしれません。 録されていなければ 10 行目で new を使って 場合は知っておくべき話題でしよう。 インスタンスを生成し , @__instance__ に代 モジュールとバターン 蛇足ですが , パターンという用語は建築 入します。 9 行目から begin が始まっていま で使われていたものに由来します。文献と ところで , s ⅲ gleton という言葉はデザイン すが , これは確実に Thread. critical を解除す パターンの用語で , 「あるクラスに対してイ して C. アレグザンダーの「パタン・ランゲー るために 11 行目で ensure を使いたいからで ジ』囚をあげておきます。専門家の間では ンスタンスが 1 つしかないことを保証し , そ す。そして 15 行目で@ーーⅲ s 面 lce ーーを返して アレグザンダーの考え方に対する批判も多 れをアクセスするためのグローバルな方法 クラスメソッドの定義が終わります。 くあるようですが , この本をめくると , 有機 を提供する」パターンです。パターンという 参考までに , もしスレッドセーフにして 95 極めよ Ruby 道 伝授 !

作り方がうまい社員がいたとします。見や すく , 過不足がなく , 誰もが満足できる資 料を作る人。そういう人は重宝されるでし よう。しかし , その人が出世して社長にな ったとします。社長になってまだ資料を自 分で作っていては , さつばり仕事が進まな いでしよう。出世すれば , 自分自身の技能 よりも , 人をうまく使って仕事を任せるこ とが必要なのではないでしようか。もしす べてにわたって能力を持った人がいたとし ても , 全部のことを 1 人でやっていたら時 間がかかりすぎます。 [ 参考文献 ] ( ☆が付し、たのはとくに役に立った文献 ) ☆ fBooch 法 : オプジェクト指向分析と設 計第 2 版』 , Grady Booch 著 , アジソン・ ウェスレイ / 星雲社 ☆『オプジェクト指向方法論 OMT モデル化 と設計』 , ランポー他著 , プレンティス ホール / トッパン ☆『オプジェクト指向システム設計』 , E ・ ヨードン著 , プレンティスホール / トッ ・『オプジェクト指向方法序説基盤編』 , ジェームズ・マーチン / ジェームズ・ J ・ オデル著 , プレンティスホール / トッパン ・『ビジネスオプジェクトユースケースに よる企業変革』 , I ・ヤコプソン /M ・エリ クソン /A ・ヤコプソン著 , アジソン・ウ ェスレイ / トッパン ☆『オプジェクト指向方法論の世界』 , アン ディ・カーマイケル編 , プレンティスホ ー丿レ / トッノヾン ・『オプジェクト指向開発の落とし穴』 , B ・ F ・ウエプスター著 , プレンティスホ ール / トッノヾン ・『オプジェクト指向システム分析 / 設計 Q &A 』 , 佐原伸著 , ソフト・リサーチ・セ ンター ・『タオ・オプ・オプジェクト』 , Gray Ents minger 著 , 技術評論社 ・「オプジェクト指向入門』 , 酒井博敬 / 堀 近年 , プログラムの規模は増大してきて います。一昔前なら数十 K バイトあればそ こそこ大きいプログラムでしたが , 現在は 単にウインドウを表示するだけで , 数百 K バイトも必要になるほどです。 GUI のイン タフェイスなど , 要求される機能もますま す増えています。昔のプログラマは係長の ようなもので , 1 個 1 個の機能に直接手を下 すことができたのですが , それがいつの間 にか , 部長・社長レベルになってしまいま した。こうなると , すべて自分でやること は不可能です。だからこそ「任せる」こと , 内一著 , オーム社 ・「オプジェクト指向アプローチーその全 貌ー』 , デビット・ A ・テイラー著 , アジ ソン・ウェスレイ / 星雲社 ☆『ゼロからわかるオプジェクト指向の世 界ビジネス活用のために』 , 岩田裕道・ 手島歩三著 , 日刊工業新聞社 ・『かんたん UML 』 , オージス総研著 , 翔泳 社 ・「憂鬱なプログラマのためのオプジェク ト指向開発講座』 , Tucker! 著 , 翔泳社 ・『プログラミング言語 C + + 第 3 版』 , Bjarne Stroustrup 著 , アジソン・ウェスレイ / ア スキー TANSI C / C + + 辞典』 , 平林雅英著 , 共立 出版 ☆『ジャスト JAVA 』 , PETER van der LIND EN 著 , アスキー ・「 le Java DeveIopers Almanac 』 Patric k Chan 著 , Addison Wesley ・『サクサク Smalltalk 』 , サイモン・ルイス 著 , 東京電機大学出版局 ☆「 Oxford EngIish D ictionaryJ , Oxford U niversity Press ・『 CoIIins CobuiId EngIish Dictionary 』 , H arper C011ins Publishers ・「リーダーズ英和辞典』 , 研究社 ・「新英和大辞典第 5 版』 , 研究社 “オプジェクト指向”を こう考えてみよう つまりオプジェクト指向が必要になってく るのです。 自分がやりたくても , 発想を切り替え , オプジェクトを信じて仕事を任せる , 不安 は感じても心の内にとどめる , 実現された 機能が多少気に入らなくても致命的でなけ ればそれでよしとする , こういう姿勢が要 求されます。 しかしこれは , 言うは易し行うは難しで あって , わかっていても自分でやりたくて むずむずするときはあります。まあそれは がまんしなくてはいけないでしよう。 ・「ランダムハウス英和大辞典』 , 小学館 ・「英語語源辞典』 , 研究社 ・『ロワイヤル仏和中辞典』 , 旺文社 ☆『研究社羅和辞典』 , 研究社 ・「英単語記憶術』 , 岩田一男著 , 光文社 ・「英語のなかの歴史』 , オウ工ン・パーフ ィールド著 , 中央公論社 ・『英語の語源』 , 渡部昇一著 , 講談社現 代新書 ・「広辞苑第 4 版』 , 岩波書店 ・「人月の神話』フレデリック・ P ・プルッ クス・ Jr. 著 , アジソン・ウェスレイ / 星 雲社 ・「シミュレーションの発想』 , 中西俊男著 , 講談社プルーバックス ・『効果的プログラム開発技法第 4 版』 , 國 友義久著 , 近代科学社 ・「構造化分析とシステム仕様』 , Tom De Marco 著 , 日経マグロウヒル社 ・『プログラミングの壺』 , P ・ J ・プローガ 著 , 共立出版 ☆『 ER モデル・システム分析 / 設計技法』 , 林衛著 , ソフト・リサーチ・センター ・「オプジェクト指向からエージェント指 向へ』 , 本位田真一 / 大須賀昭彦著 , ソフ トバンクパプリッシング ・「水素製造法』 , かんべむさし著 , 徳間文 特集プログラミング入門 “オブジェクト指向”を考えてみよう 59

Object" と℃ riented" に分かれます。、℃ⅱ e nted " のほうが取っ付きやすそうなのでこち らを先に見てみましよう。 Oriented" を辞書でひくと , 形容詞とし て「・・・志向の , ・・・優先の」と出ています。し かしこれは明らかに % ⅱ ent " の過去分詞形 派生なので , " 0 ⅱ ent " も見てみましよう。こ れは「昇る太陽」という意味のラテン語を語 源としています。名詞としては「東方」であ り , 「オリエント文明 ( ョーロッパの東方に 存在した文明 ) 」のオリエントと同じです。 これが動詞になると「東に向く・向きを方 位に合わせる・判断する・適応させる」な どの意味になります。 0 ⅱ ented の例文には 「 male-oriented ( 男性優位の ) 」とか「 profit-or iented ( 利益追求型の ) 」という語が出ていま す。つまり、℃ riented" とは , 意識の方向が 何かに向かっている→何かを主要なもの / 主役とみなすという意味になります。 Object-Oriented" とはとりあえず , 「 Obj ect を主要なものとみなす」ことであると考 えていいでしよう。では , 肝心の、 Object" とは , いったい何者なのでしようか Obje 供の多彩な意味 "Object" を辞書でひくと , 「物・物体・ 対象・ ( 文法の ) 目的語・おかしなもの・目 的」などと出ています。 'Object-Oriented' の Object はどれに当たるでしようか。「この 中で『おかしなもの』とか『目的語』というの は明らかに意味が違うし , 『目的』というの も , 目的はいつだって主要なものなのでわ ざわざ Oriented を付けるまでもない。『物』 という意味だろうか。あるいは「対象』かな」 と考えるのが自然ですね。 一般的には , オプジェクトとは「もの」で あると理解されています。そうはっきり書 いている本もあります。この場合の「もの」 には抽象的なものや事象なども入ります。 実際上は「まとまったものとして扱えるデ ータの集合」をオプジェクトとすることが 多いでしよう。また , 現実世界とプログラ ム内部の世界を分けて , 「オプジェクトと は , 現実世界に存在する『もの』をプログラ ム内部に写像したものだ」とする立場もあ ります。 しかし , オプジェクトを「もの」と理解し ていいでしようか。やつばりすっきりしな い感じが残りませんか。 もう一度辞書を見てみましよう。名詞の object" の後ろに , 同じ綴りの単語があり ます。「不服である・反感を持っ・反対す る」などの意味を持つ動詞です。辞書によ っては同じ単語の名詞用法と動詞用法とな っているかもしれません。もし , Object-Ori ented の Object がこれだとしたらどうでしよ う。「『反対する』を主要なものとみなす」と いう意味になりませんか。もっともこれは 動詞なので , そういうことはありえません しかし「物」と「反対する」が同じ単語にな っているとは不思議です。英語国民の感性 はとてもユニークです。・・・・・・いや , ユニ クで済ませてはいけません。実はこれが 「オプジェクト」の意味を解くカギとなって いるのです。 これを解くために , ・℃ bject " の語源を調 べてみましよう。 object( 名詞 ) も , object ( 動詞 ) も , ラテン語の。 bjec ⅲ s が源となっ “オプジェクト指向”を こう考えてみよう ています。これは ob + ject(us) に分けること ができます。 ob は「逆らって・前に向かっ て」などを表す接頭辞です。一方 , ject は 「投げる」を意味します。これはほかにも " ej ect " ( 排出する ) などの語に現れています。 「向かって投げる」「逆らって投げる」という 意味より , 「非難・反対・対立」などの意味 が生まれました。また「精神へ投げられた もの」という意味から objectum 「目的・対 象」の語ができました。 ラテン語の objectus や objectum は , フラ ンス語を経由して英語に取り入れられます。 英語に入ってからも object にはさまざまな 意味が付与されました。 OED (Oxford Engl ish Dictionary : 世界最大の英語辞書 ) によ ると , 名詞・形容詞 ( 現在は廃語 ) ・動詞と して , 二十数種類の項に分かれる意味があ ります。 こでは名詞に限って , 主な意味 を抜き出してみましよう (Fig. 3 ) 。 一見すると多様ですが , もともとの「向 かって投げられたもの」という意味と , ど こかでつながっていることに気づきます。 まず反対意見はほばそのままの意味です。 進む向きに逆らって投げられるから障害物 ともなります。また , 精神・感覚へ向かっ てイメージを投射する物体となり , それは Fig. 3 それぞれの用法の使われた年代 ( OED に載っている用例 ) 14 1 5 1 6 1 7 1 8 1 9 20 (Century) ( 1 ) 「反対意見 ( 廃義 ) 」 1380-1617 ( 3 ) 「 ( 認識の対象としての ) 物体」 1398- ( 2 ) 「障害物 ( 廃義 ) 」 1450-1564 ( 4 ) 「奇妙なもの・芸術作品」 1588- ( 8 ) 「 ( 文法用語 ) 目的語」 1727- ( 7 ) 「 ( 哲学用語 ) 客体」 1 513- ( 6 ) 「目的・目標」 1597- ( 5 ) 「 ( 感覚・認識・行為のための ) 対象」 1586- 特集プログラミング入門 “オブジェクト指向”を考えてみよう 55