vieweditattachhistorytopchangessearchhelp

第21回


■SqueakではじめるSmalltalk入門   第21回


 本連載では、名前は知っていてもなかなか触れる機会のないSmalltalkについて、最近話題のSqueakシステムを使って紹介しています。今回はオブジェクト指向の“種類”と継承の関係についてです。

 継承とは、端的には、定義済みのクラスからの差分を記述するだけで、新しいクラスを定義できるようにするための“端折り”目的の機構です。ただその位置づけや意味は、その処理系が拠り所とするオブジェクト指向が「何を重要視するか」により様々です。たとえば、古くからのMacユーザーにはお馴染みのHyperCard(HyperTalk)ではイベントの伝達系路、あるいは「委譲」の意味を持たせていたり、C++の流れを汲む静的型チェックを行なう言語では多態性を実現するための「派生型(サブタイプ)」定義に欠かせない機構であったりします。

 人によっては「定義など存在しない」とまで言い切る“オブジェクト指向”ですが、私が調べたところでは、そのオリジンはかなりはっきりしていて、ほぼ2つに絞ることができます。ひとつは、アラン・ケイが最初に「オブジェクト指向」という言葉を作ったときに想定していた意味合いで、「メッセージ指向」【註1】と呼ぶべき考え方です。もうひとつは、C++の設計者であるビアルネ・ストラウストラップが1980年代半ば頃までにまとめた「継承によるプログラミング」と称されるものです。

 ケイのメッセージ指向は、簡単には、「パーソナル・コンピューティングに関わるすべてを“オブジェクト”とそれへの“メッセージ送信”で表現すべし」というドグマにより成り立たせようとする世界観で、哲学的には、ライプニッツのモナド論に通じるところがあります。また生物学的には、すべてが細胞(あるいは機能性タンパク質)で成り立ち、その間でのシグナル授受で営まれる多細胞生物の活動の様子をヒントに、それをシステムソフトウエアへ応用したものとも言われています。Smalltalkは、この「メッセージ指向」を1970年当時の技術で実践し、その有効性を実証するために作られたシステムだと考えることもできます。

 他方で、ストラウストラップの考え方は「メッセージ指向」とはまったく別の独自のアプローチで、C++の仕様策定と実装を通じて整理されました。これは、ユーザー定義型による抽象化手法(抽象データ型)に、継承と仮想関数の動的結合を組み合わせたもので、オブジェクト指向の定番三要素である「カプセル化(抽象データ型、情報隠蔽とも)」「継承」「多態性(多相性、動的結合とも)」の元になった考え方です。ポイントは、SIMULAという言語で初めて言語機能として備えられた「クラス」【註2】を、ユーザー定義型、つまり抽象データ型に見立て、その継承機構を型の派生(サブタイピング)に流用するところにあります。クラス中心の考え方なので、個人的には簡単のため「クラス指向」と呼ぶことにしています。

 「オブジェクト指向」の名の下に、両者は渾然一体として語られがちで、それゆえにオブジェクト指向という考え方は非常に分かりにくいものになってしまっていることは、皆さん、すでにご存じのとおりです。長い歴史の中で繰り返されてきたオブジェクト指向言語間論争のようなものも、根は両者の混同にあると言って過言ではないでしょう。たとえば“純粋なオブジェクト指向”では「すべてがオブジェクトでなければならない」からC++やJavaはてんで駄目だ…とか、Smalltalkで既存のクラスのソースが公開されていたり、それを動的に変更できるのはオブジェクト指向の原則である“情報隠蔽”に反する…などといった類はその典型です。クラス指向において、ユーザー定義型が基本型と区別なく扱えるようになっているべきではありますが、すべてがユーザー定義型である必要はありません。また、オブジェクトそれ自体よりメッセージングのほうに重きを置くメッセージ指向においては、C++などのクラス指向で言うところの「データ型としての完全さ、安全性」にはあまり力は注がれてはいません。

 継承についても同じようなことが言えます。データ型というものを拠り所として物事の抽象化を行なおうとするクラス指向においては、派生型を作るために使われる継承機構というものはたいへん重要な役割を担っています。仮想関数(派生型により再定義されることが期待されるメンバー関数)による動的結合、つまり“多態性”も、継承機構あっての話です。もっとも、クラスとその継承機構を、データ型とその派生に流用することには、理屈の上では問題があることがウィリアム・クック【註3】によって証明されていたり、現場でも継承はトラブルを起こしがちであることが分かってきているなど、クラス指向の屋台骨である継承の地位は現在、急速下降気味だったりもしますが、それはまた別のお話。

 一方で、メッセージ指向を拠り所とするSmalltalkにおいて継承は、クラス指向をあえて意識しないかぎり【註4】、冒頭で述べたように、既存のリソースの再利用のために用意された便利な機構に過ぎません。たとえば静的型チェックを行なわないSmalltalkにおいては多態性も、継承を用いずとも実現可能です。さらには、継承が引き起こす型安全性を壊す深刻な問題などともまったくの無縁でいられます。そんなわけで、継承については当面「使えるときに好きに使う」程度のものと考えておけばよさそうです。

 Smalltalkでは、既存のクラスを継承して生じるクラスのことを「サブクラス」と言い、相対的に、継承の元となるクラスを「スーパークラス」と呼びます。引き続き、BankAccountのサブクラスとしてStockAccountを定義し、株式口座オブジェクトを作ってみましょう。


註1:ケイらは、1970年代前半までは実際に、彼らの“オブジェクト指向”を意味する局面で「メッセージ指向」という言葉を使っていました。

註2:「クラス」と「オブジェクト」は、シミュレーション用言語であったSIMULA-Iにおいて「アクション」と「プロセス」と呼ばれていた言語機能を、汎用言語のSIMULA-67(のちにSIMULA)にバージョンアップする際に言い換えたのがその始まりです。「疑似並列処理」のための機構でした。このSIMULAの「クラス」and/or「オブジェクト」という言語機能をヒントにして、抽象データ型(ユーザー定義型による抽象化手法)に加え、クラス指向やメッセージ指向などのオブジェクト指向といった新しいパラダイムが生まれたわけです。

註3:継承とサブタイピングの関係の研究に詳しいウィリアム・クックは、AppleScriptの主要開発メンバーとして、実は、我々Macユーザーと大変関係の深い人物でもあります。

註4:Smalltalkでも、制限付きながらクラス指向を実践することは可能です。むしろ、メッセージ指向と衝突したり矛盾しない範囲であれば、クラス指向のエッセンスを汲んだ設計が強く推奨されるのが普通です。

このページを編集 (5669 bytes)


Congratulations! 以下の 1 ページから参照されています。

This page has been visited 1172 times.