日々の破片

_ COMSOM思い出してみたり

まだ1990年代の最初の頃、Javaという言語が見えもしないころ（とは言え、元ネタのセットトップボックスはあったかも知れないけど）、実装継承があるからSOMえらい、COMには継承なんてないじゃん、というようなSOMな人に対して、へーんだ、COMにはインターフェイス継承があるもんね、というような論争があって、それから10年くらいしたら、みんなインターフェイス継承でコンポジションでどうしたとか言い出したもんで、なんだ、確かにSOMは消えるはずだよな、とか思ったものだという昔の話。

あのあたりの話ってどっかに残ってないかなと探したら、あるもんだ。

IBM System Object Model

このWikipediaに書かれている内容は、僕が覚えているSOM派の言い分に沿っている。

The most notable difference between SOM and COM is support for inheritance — COM does not have any. It might seem odd that Microsoft produced an object library system that could not support one of the most fundamental concepts of OO programming, but they did have their reasons. The main issue is that it is difficult to know where a base class exists in a system where libraries are loaded in potentially random order. COM demands that the programmer specify the exact base class at compile time, making it impossible to insert other derived classes in the middle (at least in other COM libraries).

おおざっぱに訳すと、「SOMとCOMの一番の違いは、継承のサポートだ。つまり、COMには継承は無い。MSのオブジェクトライブラリには、OOプログラミングの肝の継承が無いんだぜ。くそめが（odd）。まあ、連中には理由があるらしい。ライブラリのロード順がわからないから基底クラスがどれかわからないんだってさ。へへ。COMはプログラマにコンパイル時に基底クラスを特定するように要求してるから、派生クラスを間に挟むことも不可能なんだぜ（少なくても他のCOMライブラリについてはね）。どんくせー」

それに対して、ドンボックスがThe Component Object Model and Some Other Model:A comparison of technologies revisited yet again で語る。

COM is a way of life

じゃなかった。

Traditional OO inheritance is fully supported at the interface level. In lieu of implementation inheritance, COM offers aggregation to allow implementation hierarchies. The laws of IUnknown allow for a clean object composition architecture that while simple, is somewhat different than the circa 1985 approach to reuse most of the world is used to.

「インターフェイスレベルでだったら、伝統的なOOの継承は完全にサポートしてるぜ。実装継承の代わりにCOMは集約を使って実装の階層構造だって実現できるんだ。IUnknow則を使えば、クリーンなオブジェクトのコンポジションモデルを構築できるぜ。しかもこいつは、1985年頃の手垢にまみれた「再利用」とは違って、シンプルだい」

で、21世紀になってみたら、「MSのCOMには継承ないでやんの。バーカ」とか言ってた連中側が、implements BaseInterfaceとか書いてvoid foo() { base.foo(); }とか書く方法を持ち上げまくってたり。

一方、今のぼくたちは、もっとシンプルに

class Foo
  def do_something()
    ...
  end
end
class Bar #ここには何もない
  def do_something()
    ...
  end
end
a = []
a << Bar.new
a << Foo.new
...
a.each {|e| e.do_something }

とか書いてるわけだ。

というようなことを「ポリモーフィズムは継承の面白い副作用..なんかじゃない」を読んでて思い出した。

歴史の解説：COMSOM論争の時代には、（エンタープライズでは）OOのメリットは「再利用性」という「生産性」に関する呪文とみなされていた。

したがって、継承が今になってみるとばかばかしいほど重視されていた。

COMはコンポーネント指向（バイナリの流通）も目的だから、コンポーネントを集約（むしろ内包）して再利用できれば良いので、インターフェイス継承さえあれば（これはC++でのポリモーフィズムのために必要）それで十分に役に立ったのだ。というよりも、再利用単位がコンポーネントなので、はなから継承スパゲッティみたいなものも起きなかったし（とは言え、DLLスパゲッティが待っていたというオチはつくのだけど）。ポリモーフィズムについては、名前によりメソッド解決のIDispatchインターフェイスがVB用にあったので、こっちが便利だった（それが、ActiveScriptingに繋がることになるのだと思うし、今の動的言語の受容に対するベースになったのではないだろうかな）。