私が愛するオブジェクト指向とそれを使わない理由
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思い��す。
なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。
オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smalltalkのtは小文字です
“オブジェクト指向”の本質 - Smalltalkのtは小文字です
私がオブジェクト指向を愛する理由
私はプロトタイプベースオブジェクト指向言語を自作したり、「ぼくのかんがえたさいきょうのオブジェクト指向」を妄想する生粋のオブジェクト指向好きです。
Cyan, Yet Another New language - takuto_hの日記
そんな私がオブジェクト指向を愛する理由は大きく分けて６つあります。
1. すべてをメッセージパッシングとしてとらえるという理念
これはSmalltalkの（より正確にはアラン・ケイの）オブジェクト指向にあたります。以下はメッセージパッシングを軸とするオブジェクト指向の理念を学べる良書です。
SMALLTALKで学ぶ オブジェクト指向プログラミングの本質
- 作者: 青木淳,浅岡浩子,澤本依里
- 出版社/メーカー: 日経BP社
- 発売日: 2008/07/24
- メディア: 単行本
- 購入: 14人 クリック: 408回
- この商品を含むブログ (39件) を見る
Smalltalkは、オブジェクト同士のメッセージのやり取りによってプログラムを表現しようとしました。それが正しい抽象化かどうかはさておき、プログラム内のオブジェクトがまるで生体内の細胞のように情報をやり取りするさまは、イメージするだけでわくわくしてきませんか？もちろんこれが単なる絵空事ではないことは本書が証明してくれます。私がオブジェクト指向を愛するきっかけとなった１冊です。
2. メタ階層
Smalltalkにはクラスがありますが、先の理念に基づくプログラミングにおいてクラスは必須のものではなく、単に効率のために導入されたととらえるべきだそうです。
すべてのオブジェクトにメソッドのコピーが含まれていたらメモリ効率が悪いので、メソッドはクラスにまとめてオブジェクトはクラスを参照するようにしたとのこと。ただ、クラスを特別な存在とするのは理念に反するので、クラスそのものもオブジェクトとするためにメタクラスを導入し、メタクラスのクラスを導入し、メタクラスのメタクラスを導入しました。
なんだかとても複雑なように思えますが、グラフにするととてもシンプルです（Ruby1.9 のクラスのメタ階層を整理する ２ - Smalltalkのtは小文字ですの、「Squeak Smalltalk の場合」を参照）。このメタ階層のおかげでクラスの振る舞いに手を加えることもでき、柔軟なオブジェクト指向が可能となっています。そしてなによりRubyと比べてグラフがとってもかわいいです。
3. クラスのないオブジェクト指向
クラスのないオブジェクト指向言語というとJavaScriptが思い浮かぶかもしれませんが、プロトタイプって「メソッドをまとめてオブジェクトから参照できるようにしたもの」なのだからそれってつまりクラスそのものです。そうではなくて、プロトタイプチェーンも使わず、ハッシュテーブルに無名関数を突っ込んだものをオブジェクトと呼んでもいいよね？ということです。メタテーブルを使わないLuaのオブジェクト、と言った方がわかりやすい人もいるかもしれません。あるいは『On Lisp』という書籍ではそのものずばりのオブジェクトシステムをCommon Lispで実装しています。
- 作者: ポールグレアム,野田開,Paul Graham
- 出版社/メーカー: オーム社
- 発売日: 2007/03/01
- メディア: 単行本
- 購入: 10人 クリック: 146回
- この商品を含むブログ (128件) を見る
先ほどクラスは必須ではないと申し上げたように、ある意味これがオブジェクト指向の源流にもっとも近い形なのかもしれません。『On Lisp』を読めばわかりますが、実装も簡単です。クラスがないために生成したオブジェクトの振る舞いをあとから変えにくいという欠点はありますが、こんなオブジェクト指向もあるよ、という意味ではきっと興味深いと思っていただけるはずです。
4. CLOS(Common Lisp Object System)
オブジェクトシステム界の異端児といっていいであろうCLOSです。CLOSの解説は『On Lisp』やfireproject.jp - このウェブサイトは販売用です！ - クラス ジェクト ファイヤー パターン ファイル リソース 関数 ゾンビ リソースおよび情報、ホームページ移転のお知らせ - Yahoo!ジオシティーズにお任せします。これからCLOSを勉強する方は、きっとJavaScriptのオブジェクト指向を学んだ時の何倍も驚嘆することでしょう。一般的なオブジェクトシステムと比べてできることはさほど変わりませんが、何よりその実現方法は一見の価値ありです。
5. 多重継承問題
やってきました、多重継承です。この問題は「クラス」という概念が生まれた時点で自然と付きまとうものです。つまりクラスさえなければ……でもクラスがないと……といった感じで妄想がはかどりますが、それはさておき。
クラスにはメソッドがまとめられており、時としてこれを再利用したくなります。そこでクラスからクラスへの参照を持たせる、いわゆる継承をするわけですが、ここで問題が生じます。多重継承を許すと継承関係がグラフになるので、メソッドの探索順序を一意に定めにくいのです（なお、C++ではもう一つ、メモリレイアウトにかかわる問題が起きますが、これは省略）。
これまで様々な言語がこの問題の解決策を提示してきました。
- Java
- 実装の多重継承禁止。再利用したければ合成と委譲を使う。
- Python, Perl
- 多重継承許可。C3線形化でメソッドの探索順序を一意に定める。
- Ruby, Scala
- ミックスインのための機構を導入。Scalaのトレイトは後述のトレイトとは違い、Rubyのモジュールに近いです。
- Squeak Smalltalk, Perl, PHP
- トレイト（PerlではRoleと呼ばれる）を導入。
Javaのやり方が窮屈なのはみなさんご存知でしょう。何度委譲のためだけの中身のないメソッドを書いたことか……。
PerlやPythonに導入されたC3線形化は、ほとんどの場合でメソッドの探索順序を望み通りに決定してくれるアルゴリ��ムです。しかしながら、Class::C3, Algorithm::C3 を勉強したよ！ - IT戦記の最後の方にあるように、もしかするとうまくいかない可能性があります。
ミックスインというのは、多重継承の使い方を表すものです。他のクラスを継承しないクラスならばいくら多重継承しても問題ありませんから、このような継承を指して特にミックスインと呼びます。Rubyはモジュールという多重継承可能なメソッドの集まりをクラスとは別に導入し、クラスは単一継承のみ・モジュールはインスタンス化できないようにすることで、ミックスインを推奨する文化を作り上げました。ただし、モジュールがモジュールを多重継承すると当然問題が生じる可能性があります。
Perlなどに実装されているトレイトは、ミックスインとは少々異なるアプローチです。トレイトはメソッドの集まりですが、クラスから継承するのではなく、クラスにメソッドを追加することで拡張します。
真にただのメソッドの集まりであるトレイトを足したり引いたりすることで衝突を解決するさまは、ハッシュテーブルに無名関数を突っ込んだだけの原始的なオブジェクトを操作しているようにも思える趣深いものです。ある意味原点回帰ともいえるでしょう。
私がオブジェクト指向を使わない理由
至極単純です。
「私がプログラムを書く時に必要としないから」
です。
私はよく言語処理系を書きます。今まで様々な言語で言語処理系を書いてきました。JavaやらC#やらRubyやらCommon LispやらSchemeやらJavaScriptやらHaskellやら……。そして現在はOCamlに落ち着いています。OCamlはオブジェクトシステムを持っていますが使っていません。
昔はJavaやC#で字句解析器や構文解析器をオブジェクトにしたり、構文木をオブジェクトにしたり、VMの命令をオブジェクトにしたりと、いろいろ試しました。
字句解析器や構文解析器をオブジェクトにしても状態がグローバル変数のように参照できるというだけで、OCamlでレコードを第一引数として渡して中身を見ながら操作するのとそんなに労力は変わりません。データの中身を隠蔽したいと思うかもしれませんがそれはモジュールで十分です。
構文木をオブジェクトにすると型検査器とコンパイラのコードが各構文要素に分散するので、とても読みにくいです。型検査モジュールやコンパイルモジュールを作ってその中で完結させた方がはるかに読みやすくなります。VMの命令をオブジェクトにした場合も同様です。
また、型推論器はバリアントとパターンマッチがないとだいぶ書きにくいです。これはJavaScriptで型推論器を書いたときに実感しました。
JavaScriptで型推論器を作りました - takuto_hの日記
つまり、私が、言語処理系を書く際に、オブジェクト指向は有用ではないのです。
最後に
この記事の要旨は、「オブジェクト指向そのものはとっても面白いから、もっと知るといいよ。でも私が作るプログラムには必要ないから使わないよ」ということです。特に後半については、「適材適所」と一言で済ませられるほど当たり前のことなので、がっかりした方もおられるかもしれません。
ただ、私が声を大にして主張したいのは、いわゆる関数型言語を好んで使う方々とオブジェクト指向言語を好んで使う方々が、お互いをよく知らないままに批判し合うのが非常にナンセンスだということです。結論から見ればこの記事は関数型言語の使用を推奨しているように思えますが、そうではありません。「私にとっては」関数型言語が適していたというだけの話です。
お互いが何を好んでその言語を使用しているのかを理解することで、言語ユーザー間のいざこざは緩和されることと思います。ここに私がなぜオブジェクト指向言語を愛しているのかを述べることで、理解が深まれば幸いです。
