抽象データ型とOOP
Simula が発明した クラスとオブジェクトは、処理とデータの両方を、しかも望むならば同時に抽象化することが出来ます。
データには型があり、静的型付け言語では昔から、データ と データ のつなぎ目（または評価するとデータになる式との）を チェックすることが出来ました。
データで型チェックできるなら、クラスやオブジェクトでも型チェックできます。クラスやオブジェクトが型チェックできるというのならば当然、データだけでなく処理も型チェックできるでしょう。
これがどれだけ凄いことだかわかりますか？モジュールのつなぎ目が正しいかどうかをコンピュータが事前にチェックしてくれるってことなんですよ！
メッセージメタファとOOP
「メッセージ」なんて単なる関数コールに、そんな大袈裟な名前を付けて...というのはよく聞くけれど、そりゃ、クラスがメソッドの束にしか見えていないからだと思うんです。
こういうのを「木を見て森を見ず」と言うのかな？ OOP なんて 人間が複雑さに立ち向かう為の技術なのだから、「森」として抽象的にとらえないと、そのパワーは構造化プログラミング++ と大して変わらなくなっちゃいます。
Simula が発明した クラスとオブジェクトは、処理とデータの両方を、しかも望むならば同時に抽象化することが出来ます。最初は「プロセス」と「アクション」と言っていたらしいけれど、これに、クラス（概念）と インスタンス（実例）というメタファをこれに紐づけることで、この構造化エンティティ の抽象化能力を格段にアップさせました。（おまけに継承という最終兵器までど〜んとプレゼント）
処理の構造化の部品としてのコイツは、サブルーチンのくびきを離れたいる点、 コルーチンに似ていますが、next next と継続するのでなくって、任意のコードポイントへジャンプできる かなり邪悪なやつです。
しかし、こんな複雑なの人間の統制下におけますか。そもそも複雑さに適応できない人間のための武器が複雑でどうしますか...orz ――という問題に対して、情報構造に与えた「クラス・インスタンス」というメタファと、同じくらいにドカン強烈なメタファを、処理の方にも与えちゃえ！ というのがメッセージだと思います。（単に コレ↓を 元に妄想を広げただけなんですが。）
In our experience, the SIMULA notion of class and instance is an outstanding metaphor for information structure. To describe processing, we have found the concept of message-sending to be correspondingly simple and general.
超訳： 経験上、クラスとインスタンスというSIMURAの概念は 情報構造のピカいちのメタファです。 同様に処理の表現においては、 メッセージ送信というコンセプトがシンプルかつ一般的であることを発見したのです。
http://users.ipa.net/~dwighth/smalltalk/St76/Smalltalk76ProgrammingSystem.html
まともに 責務分散協調系なOOP で設計してみて、それをシーケンス図をまじめに引っ張ってみたり、CRCセッションしてみたりすれば、あまりの複雑さに辟易としてしまうと思います。こういう複雑さを扱えてしまうのは、複雑さに対し、個々のクラス/オブジェクトに担った責務にふさわしい名前を与えてみて、深く考えないことで対処してるからです。要するに抽象化です。
抽象データ型のOOP が人間の妄想力に対して脆弱なのは、やっぱりデータ型というモヤモヤンイメージは、その箱の中と外殻を考えるときにはギュッと凝集度の高い 良いイメージを提供するのですが、箱と箱 の間を考えるとき、何もイメージを助けてくれないからです。助けてくれないどころか、どうしても、いろんな箱を使って何かをする 神様だとか、箱と箱をくっつけるグルーをイメージしてしまう。使われる側でしかない、というちょい悪めなイメージが付いてきてしまう。個々のオブジェクトの外は「処理」が充ち満ちています。
メッセージが与えるモヤモヤンイメージは、凝集したオブジェクトの間にはメッセージという（電波みたいな）形のないモノが飛び交っていて、個々のオブジェクトの外は「空」が満ちています。間に何もないけれど、距離もゼロじゃない、という 疎結合 なモヤモヤンイメージが得られるのが最高ですね。
逆に、森を見れるのならば、メッセージなんて補助輪はいらないわけで、本質的にはメッセージメタファは、単にOOPなるあやふやなモノに、認識可能な形を与える外殻にすぎないのかもしれません。(既に認識しているなら、殻を通して見る必要はない）
よいメタファは入門者にとって真実と区別がつきません。（ベテランにとっては真実と非なるモノであっても）物の見方を狭めることで、道をまっすぐ進めるようにする道具だとおもいます。また、本当に良いメタファはエッセンスと区別がつかなくなるとは思いますが、メタファであれば、排斥は可能だと思います。
蛇足
もちろんのエントリはオレオレです。たとえば、肝心の、メッセージメタファを動的ディスパッチの間についてなんにも言及していなかったり。(むしろ、メッセージメタファってそっちじゃんという^^;）
蛇足2
メッセージと言う語が与えるイメージが、「如何にも並列でござい」で嫌だ、というなら、サッカーでパスを回しながらボールを運ぶイメージが、良いかもしれないと、オリンピックみながら思ったです。（所詮思いつきの垂れ流し:深く考えていない）
今時のOOP
根拠レスですが、なんかこんな感じに落ち込んでいるイメージはあります。
* * *
始めにオブジェクトがあった。オブジェクトがなにで出来ているかとかはどうでもよろしい。
オブジェクトを基本構造単位としてプログラムを構造化する(分割する)。オブジェクト間には関連があって、継承という名の関連（継承という名は 歴史的経緯によるもので、名自体に意味はない）と、所有 という名の関連だ。まぁ、継承はなくても要は足せるが。
オブジェクトにシステムが持つ責務を分割し、責務をイメージさせる名前を付けよ。また上手くハマれば 静的型チェックが効率的に働くだろう。（ただし、完璧にはほど遠いので、自動テストの構築は必須だ）
* * *
このOOP の出自は、メッセージメタファ OOP の影響下で育てられた、というのが定説だが、抽象データ型の OOP の、何の目印もない荒野を、迷い無く渡り切った猛者がいたという説もある。(しかし、多くのプログラマは荒野で息絶えた）
