こう、稀に来て妙なことを書き込む癖が治りませんね。SUEです。（アカウント作り直しましたが、前垢に特別想い入れはないので心配無用です）

さて、今回の用事はオブジェクト指向の問題についてここの優秀な方々に意見を募りたかったからです。
この話題、オブジェクト指向、でググるだけでいくらでも批判は見つかりますが、僕なりに問題の本質とその解決法まで考えたので、ぜひフィードバックください。
結構頑張って書いてしまったので、後ろのほうからでもいいので読んでいただきたいです。


一つはじめに注目したのは、例外にまつわる話題でした。例外ってそもそも必要なんでしょうか？
goなんかは複数返り値で例外相当のものを表せるわけで、そのほうが例外機構に苦労するよりいいと思いますね。
そもそも例外の目的は相手とこちらの処理を分離することの筈なんでしょうが、結局キャッチする必要がでてくるわけで本末転倒です。
いまどき言語Swiftにも例外はないそうですし。

思うに、例外は相手オブジェクトに仕事を投げるだけ投げて、どうしてものとき仕方ないから例外として受ける、という発想があるのでは？
そう考えると、オブジェクト間のメッセージング全体に同じ発想があるような気がします。
相手の処理はなるべく関知しない。仕事は一方的に投げるだけでなるべく済ます。という考えが、なんとなくわがままのように思えました。気分的に。
現実だったら相手の事情は少しくらい知ってるほうが上手くいくし、例外なども相手が何を投げてくるか想定しておいて書いたほうが上手くいきます。
あ、まだまだ続きますので、まだ石を投げないで。


もう一つ行き当たったのが、オブジェクト指向の成り立ちでした。
元祖オブジェクト指向言語といえば、Smalltalkですね。
Smalltalkの最も重視していたのは実はオブジェクトではなくオブジェクト間のメッセージングでした。
今のほとんどのオブジェクト指向言語では、そこんところが曖昧になっているような気がします。
普通にプログラミングをしていても、オブジェクトをどう切り分けるかより、オブジェクト間でどう連携するかに苦労すると思います。これ、僕だけじゃないですよね？
ですから、もしオブジェクトそのものとは別に、オブジェクトの関係性をよく記述する方法があれば、プログラミングはもっと楽になるんじゃないでしょうか。

で、上の例外の話と組み合わせると、Smalltalkのメッセージを送るという考えが、わがままであるという点で完璧ではないと考えています。
関係性を「相互に」記述する方法が何か必要ではないでしょうか。



そして最後に見たのは関数型との比較でしたね。大体関数型（中略）言語がいかに優れているかという内容でしたが。
確かに関数型言語は出来がいいです。それはなぜか。非常にコンピュータのやり方と一致しているからです。
コンピュータのやり方とは、小さなものを組み合わせて大きい処理をするボトムアップ型です。
しかし一方、人間のやり方は、大きな概念から徐々に細かくしていくトップダウン型…が多め、というか、より自然です。
ここで、関数型言語の難しさが現れてきます。
オブジェクト指向はその点、トップダウン型に近いものではありますが、上記の問題もあって必ずしも自然ではありません。



批判するのはここまでです。
もっと大事なのは、これらをどう解決するかという問題です。



僕が思いついたのは、状態（概念）と物体を分離して考えることです。
波という「状態」は、特定の水の塊を表しているわけではありません。連続した水の動きに波という名前を与えているのです。
人間は、ものを状態や概念で捉えるのが得意です。先ほどトップダウン型がどうだとか言いましたが、より正確には状態で捉えるのが自然ということです。
一方コンピュータは、水の動きを一つ一つシミュレートするような実体の処理は人間をはるかに上回る能力を発揮します。
この間のギャップをいかに美しく、簡潔に解決するかというのが命題です。


ここで状態（概念）についての注意ですが、必ずしも階層構造で綺麗に表せないという性質があります。
例えばサッカーという概念は、ボールや選手、フィールドなどの概念から構成されていると捉えることが出来ます。
しかし、ボールという概念は、サッカーのみならず野球やその他球技、さらにその大きさ、材質と言った概念からできています。
この多対多の関係性が、複雑性を生みます。そして複雑であることが最も自然です。
複雑ですが自然なので、人間には扱いやすいです。
実際、階層構造ですべて綺麗に書こうとすると苦しいことも多いと思います。なんでも階層に当てはめるのは不自然なので。
だからこそ、（複雑な）関係性だけを簡潔に書く方法が必要で、それをするのはコンピュータではなく人間の得意技です。



さてこの概念たち、どう書いてどう扱うかということですが、実はすでに方法が存在します。
役割としてオブジェクトに与えればいいのです。役割は、Rubyで云うモジュールとほとんど同じです。
役割には、他の役割との関係と、自分が果たすべき役割が記述してあります。

具体的には、
●他オブジェクトとの通信方法……具体的にどう通信するか書く。下記も参照。
●自分の出来ること……役割特有の能力を関数として呼べるように書く。
●自分のするべきこと……中身の無い仮想関数として書く。
└→役割や概念自体は実際のデータを持たないため、getterやsetterを仮想関数として書く？
を書きます。

ボールという役割を持つオブジェクトを作ったら、そのオブジェクトにはボールらしく振る舞うことが期待されます。
その振る舞うべきボールらしさ、についてはボールの役割に既に記述してあります。

役割を与えられたオブジェクト自身は、なるべく内にこもって自分の役割を果たすことに専念します。
他オブジェクトと通信する必要があるときには、役割に書いてある通りに通信します。
勝手に定義した方法では、通信は不可能にするということです。
通信の方法は様々で、今までのように関数として仕事を投げるものばかりではないでしょう。
会話するような書き方がやりやすいのが理想です。たとえば、 みたいな？（もちろん適当です）
この擬似コードみたいなのはABどちらにも共通して必要なものですが、実際Aに書くかBに書くか、それとも分割して書くのかは議論の余地があると思います。


こうすることで、曖昧になりがちな「型安全性」という言葉の意味も見えてきます。
型安全性とはズバリ、役割をしっかり確認できているかどうかという意味です。
100%型安全な言語なら、各オブジェクトはそれぞれの役割を正確に果たすだけで、プログラムは安全に動きます。

また、オブジェクト同士の関係が役割の中に明らかに定義されていて分かりやすいと思います。
実際にどういう関係をつくれば最も効率が良いか、という問題は、その時々で人間が考える必要があります。
そのとき階層化は確かにほとんどで有効ですが、それが全てではありません。

オブジェクト同士が相互参照してるようで気持ち悪い、という向きもあるかもしれません。
しかし実体を持ち合っているわけではないので問題無いです。と思います。

こうして考えると、役割の考え方は人間でも同じですね。
役割を与える人間は、それぞれが齟齬なく動けるように仕組む。
与えられた人間は、役割を精一杯果たす。他人と係るときは、相手の役割を鑑みて正しい方法を選択する。
すごく自然な考えなのではないでしょうか。
ただコンピュータは人間と違って柔軟さがないので、人間のように異常事態に役割を越えて対応することはできませんし、してはいけません。
想定される事態は全て書いておきます。



さてさて。ここまででもかなり異論が出てきそうです。
僕が問題としているのは、言語仕様よりむしろ考え方の方だということを強調させていただきます。
だって言語仕様の話とかよくわからないし。
でも、どんな言語・さらには環境にも適用できる話だと思います。
概念や役割を決め、実体に与える。各実体は役割を果たす。
こんなふうに少し考え方を変えるだけです。


で、仕上げとして、役割を複数もつということを考えます。
学校の先生は家庭に帰れば親という役割を持つかもしれません。
というように、人間は複数役割をもつのが普通です。
これはプログラミングでもよくある話で、例えばGUIボタンは押下を待ち受ける役割と、イベントを発火する役割があるかもしれません。
しかし、役割を複数持つ場合は必ず切り替え方を定義する必要があります。
大工と消防士としての役割を持つ人は、たとえ工事中でも火事が起きたら絶対そっち優先でしょう。というように。

だいたい言いたいことは言い尽くしましたが、まだ伝わってないこと、頭のなかにあって書けていないことは間違いなくあります。
どんどん意見ください。お願いします。