日々の破片

_ オレってダレ

抽象データ型のOOP が人間の妄想力に対して脆弱なのは、やっぱりデータ型というモヤモヤンイメージは、その箱の中と外殻を考えるときにはギュッと凝集度の高い 良いイメージを提供するのですが、箱と箱 の間を考えるとき、何もイメージを助けてくれないからです。助けてくれないどころか、どうしても、いろんな箱を使って何かをする 神様だとか、箱と箱をくっつけるグルーをイメージしてしまう。使われる側でしかない、というちょい悪めなイメージが付いてきてしまう。個々のオブジェクトの外は「処理」が充ち満ちています。

メッセージが与えるモヤモヤンイメージは、凝集したオブジェクトの間にはメッセージという（電波みたいな）形のないモノが飛び交っていて、個々のオブジェクトの外は「空」が満ちています。間に何もないけれど、距離もゼロじゃない、という 疎結合 なモヤモヤンイメージが得られるのが最高ですね。

――オレオレOOPの日

ここがおもしろかった。

こないだ（と、メタファでも例えば話（今自然発生した造語）でもなく、連想なのだが、）読んだ最新宇宙論とか思い出したり。

Newton (ニュートン) 2008年 07月号 [雑誌](-)

かって、宇宙にはエーテルが満ち溢れていた。

次に、そんなものはいらないということになった。

でも筋が通らない。そこでダークエナジーを置くことにした。

名前のとおり、ダークでもやもやんなやつだとか。

あわせて読みたい

くまもと人物紀行 おてもやん(小山 良)

_ 拡張と特殊化

さて、オレはオレで、オレの言葉で継承を書く必要が出てきたので、考える。でも、まあ、考えは休むのと同じだから、まずは調べる。

そこで、やはり過激なメイヤーの若い頃の日本語化された文献を眺めてみる。多重継承がないOOPLなんてカスと言い切る男だけに、この男の継承に関する一家言には重みがある。

オブジェクト指向入門 (ASCII SOFTWARE SCIENCE Programming Paradigm)(Bertrand Meyer)

そこで、本当に、リスコフ的なるもの(メイヤーは1988年だから開放閉鎖はメイヤーのほうが早いのだが、以下のように、メイヤーの結論は異なる)に、この多重継承男が縛られているのだろうかと疑問になり、あらためて拾い読み。すると、subclassという呼び方を拒否しているくだりに注目することになった。

メイヤーは、クラスには、型という見方とモジュールという見方の両方があることを指摘する。

P.312(10.2.3)にまとまっている。

継承は拡張としてとらえられる場合と、特殊化としてとらえられる場合がある。この2つの解釈は矛盾するように見えるが、この両方に真実がある。ただし、同じ視点から見て真実があるわけではない。

繰り返しになるが、クラスを型と見るか、またはモジュールと見るかによってすべては決まる。型として見る場合、継承はis-a（……は……の一種である）という関係であり、明らかに特殊化である。"犬"は"動物"よりも特殊な概念であり、"長方形"は"多角形"よりも特殊化されている。この関係はすでに述べた部分集合の関係に対応する。（中略）

一方、モジュールという点から見ると、クラスはサービスの提供者としてとらえることができる。BはAのサービス（特性：feature）に独自の特性を追加したサービスを提供する。したがって、実現される特性という点で考えると、この関係は逆の部分集合となる。Aのインスタンスに適用される特性はBのインスタンスに適用され得る特性の部分集合である。

したがって型という点から見ると、継承は特殊化であり、モジュールという点から見ると拡張である。

この分類をJavaが手近なので当てはめてみる。ServletやActionについてはモジュールだ。一見、ある特定Webアプリケーションに特化したように見えるが、ユーザーに対しては何もしないインフラのみのクラスにfeatureを加えているのは明らかだ。このタイプは実装継承が有効に働く。

では、型と言えるのは何だろう？ …… 思いつかない。

これが、犬猫OO解釈がだめになった理由ではないか？ 少なくともJavaで構築するタイプのアプリケーションあるいはサービスにおいてのOOの利用はモジュールの側だからだ。

あるいはコレクションを考えてみる。インターフェイス継承しかしていないが、Listインターフェイスを特化したArrayListのほうがfeatureが増えている。それはそうだ。モジュールの観点からは拡張なのだから。ArrayListのArrayであるというfeatureを利用したいクライアントにとっては、Listという共通インターフェイスは意味がない。この場合はListを特化した型の実装を利用したいのではなく、ArrayListという拡張されたサービスを利用したいからだ。（それと同時に特化したList型を使いたいクライアントが存在することはまったく矛盾しない。ケースバイケースだ。ではケースは何によって生じるのか？ デザインだ。したがって設計を抜きに語ることにあまり意味がないということになる）

そこで、RubyのIOクラスとFileクラスの関係だが、IOを特化した部分集合クラスのFileクラスか、それともIOクラスのfeatureをFile用途に拡張したモジュールのFileクラスか、どっちでしょう？ おれは後者だと思うし、後者として利用している。

というよりも、型という観点（is-a）が重要視されているのは、操作の体系が同じになる点（動的束縛が利用可能）だけのようにしか読めないな。それは現在のOOPLではinterface継承やダックタイピングによって解決されていると見たほうが素直ではないか。つまり、「型」はプログラミング言語の処理系における静的な関数呼び出しの解決に関する話題なのではないか？ (10.2.2の型の視点という節は、最初は型の観点について書いているが、非集中的なソフトウェアアーキテクチャという話に変わっているし、そこであげられた型はサブクラスというよりも機能の追加に対するクライアントからの同じ操作の適用可能性についての説明になっている)

こっちではどう書いているのかな？ とは思わないでもないが、それほど興味はないのであった。

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)(バートランド・メイヤー)