id:JavaBlackさんから以下のようなツッコミをいただいた。トラックバックくれればいいのに

おれおれオブジェクト指向は何が違うのか

Java/C++/C#のオブジェクト指向的機能というのは、数学的なモデルとしては「包含関係を持つ集合をプログラマが任意に定義できる機能」と言える。包含関係というのはaggregationのことじゃなくて、集合としての包含関係なので、汎化/特化のことだ（つまり継承だ）。

http://blog.ajiyoshi.org/Entry/263/

たぶん，この人も全く分かってないと思う．憂鬱系のおれおれオブジェクト指向だと，こんな感じになります．

僕がオブジェクト指向をどうとらえているかというと、この定義がすっきりしていて綺麗だと思っている。

Rees Re: OO

以下に示すのは、[オブジェクト指向にまつわる]用語に関連づけられる機能や特性のメニューだ。オブジェクト指向というのは、このリストのいろいろなサブセットとして定義されているようだ。

1. カプセル化 - 型の実装を構文的に隠蔽できること。例えばCやPascalでは何かが構造体であるか配列であるか常に意識することになるが、CLUやJavaではその違いを隠すことができる。



2. 保護 - 型の使用者がその実装をのぞくことができないこと。これによって、ふるまいさえ変えなければ、実装を変更しても型の使用者に影響を与えないことが保障でき、またパスワードのような情報が漏れ出さないようにすることもできる。



3. アドホックポリモルフィズム - 関数やパラメータつきデータ構造がたくさんの異なる型の値をとることができる。



4. パラメトリックポリモルフィズム - 関数やデータ構造が任意の値 (例：任意のオブジェクトのリスト)に対してパラメタライズできること。 MLとLispはこれを持つ。Javaは非Objectな型のために、これを完全に持つとは言えない。



5. 全てはオブジェクトなり - 全ての値はオブジェクト。Smalltalkでは真だが、 Javaでは (int等のため) 真ではない。



6. メッセージを送ることだけができる (All you can do is send a message, AYCDISAM) = Actorモデル - オブジェクトを直接いじることはできず、それと通信する、もしくはそれを起動することのみができる。Javaにおけるfieldの存在はこれに反する。



7. 仕様継承 = サブタイピング - ふたつの異なる型で、一方の型の値がもう一方の型の値として使われても型の正当性を破らないことを言語が保障できるようなもの。(例: Javaのインタフェース継承)。



8. 実装継承, 再利用 - ひとまとまりのコードを書いたら、それと似たコード (そのスーパーセット) が制御された方法で生成できる。つまりコードをコピーして編集する必要がない。制限された、特殊な抽象化である。 (例: Javaのクラス継承)。



9. 「関数の積和(sum-of-product-of-function)」パターン - オブジェクトは (実質的に)有限の簡単な名前の集合から選ばれるキー引数を第一引数に取り、それによってメソッドを呼び出す関数として動作する。

元記事は2002年に書かれたらしいので

Javaは {1,2,3,7,8,9} があるからオブジェクト指向だ。

と書かれているけど、今日のJavaにはGenericがあるので4も備えているだろう。
mixiでJavaScriptはオブジェクト指向言語か？という論争があったみたいだけど、上記の整理によるならば、{3,4,8,9}をもつからオブジェクト指向言語と言えるんじゃない？（4はダックタイピングにより実現されていると思う。genericとかC++のtemplateは静的な強い型を持つ言語で部分的にダックタイピングを実現するための仕組みであると言えると思う。8はprototypeベースというユニークで強力なやり方で実現されている。）

id:JavaBlackさんが過去にオブジェクト指向について書いた記事ざっと眺めると、id:JavaBlackさんはJava的なオブジェクト指向がオブジェクト指向のすべてである、ととらえてるように思える。まあ、これは推測に過ぎないので、id:JavaBlackさんのオブジェクト指向の定義を聞いてみたいところ。


その上で、僕から見るとJava的オブジェクト指向というのは、静的で強い型システムと

File f = new Pipe(/* */);

のようなポインタ代入を両立させるための仕組み、としか思えない。これは結構な矛盾なので、強力な機能ではある。
（ああ、うん。確かに現実世界では継承じゃなくて委譲で解決する方がスマートな場合が多いですよね。でもそれは、継承によって解決できる問題領域が狭いということを示している。Javaにおけるオブジェクト指向的機能が解決している問題領域が主に「静的で強い型と継承を両立すること」であることを認めるならば、委譲の方がスマートっていうのはJavaのオブジェクト指向的な問題解決が力の弱い抽象化でしかなかったということを示すことになる。ということはむしろ昨日書いた文章の意図（＝Java的なオブジェクト指向の設計は間違っていた/力が弱かった）を支持することになる。）
この機能によってどんなご利益があるかというと、例えばGoFデザインパターンみたいなのを自然に記述できるようになる。Cで同じようなことをしようとしたら、C++やJavaのコンパイラがやってくれる仕事を一部自分でするはめになる。

オブジェクト指向における再利用のためのデザインパターン

価格 ： ￥5040 （税込）
メーカー ： ソフトバンククリエイティブ
→Amazonで詳細を見る
→ECナビリストで詳細を見る
おすすめ度 ：


一方僕の意見はなぜArcはとりたててオブジェクト指向でないのかとほとんど一緒。関数的な抽象が使えるなら、オブジェクト指向的抽象は別にｲﾗﾈ。
もちろん関数的な抽象とオブジェクト指向という抽象は背反ではないけどね。実際Rubyなんかはブロック構文やらLambdaクラスやらで関数的な機能を部分的にサポートし始めているし。
でもそろそろオブジェクト指向をどうこう言ってる場合じゃなくて関数型言語やそのエッセンスをいかに身に付けるかという段階じゃないのかなぁ。（この点で自分が使う言語を自分で選べない職種の人はかわいそうだ）