日々の破片

_ 広尾の交差点

右折信号が点いていても車信号が赤になった途端に渡り始める連中が数人、タクシーの激しいクラクションに押し戻される。

おお東京だな、と感じる瞬間。

_ COM

WRさんがなぜかEssential COMを読んでいるのを見て、似て非なるEffective COMを読み返してみたり。

考えてみれば、ここからどれだけたくさんの事を学んだことだろう。

Effective *らしく、この本には50のプラクティスが出ているが、それを幾つか並べてみるだけで、わかる人にはわかるだろう。

1.Define your interface before you define your class.

（クラス定義の前にインターフェイスを定義せよ）

2.Design with distribution in mind.

（常に分散を念頭に置け）

3.Object should not have their own user interface.

（オブジェクトは独自のユーザーインターフェイスを持つべきではない。ここからCOMのオブジェクトはMVCに当てはめるところのモデルを想定しているということがわかるかも）

4.Beware the COM singleton.

（シングルトンには気をつけろ。――ただし、2.がからむので通常考えられるような意味ではないのだが）

6.Interfaces are syntax and loose semantics. Both are immutable.

（インターフェイスは文法―メソッドシグネチャ―であり……次の訳は難しいな、緩い意味というのは文書化されたメソッドの説明のことだ……は変えてはいけない）

これらの規則は、COMに限定されるものではない。すべてのインターフェイスセントリク（可能）なシステムの基本となるものだ。

もちろん、ほとんどの章はC++とCOM固有の問題が扱われている。たとえば、COMのメソッド境界をまたがったC++例外をスローするな(5.)、というのは一般論としては意味を持たないし、use flyweights where appropriate(25)などはCOMのオブジェクト寿命管理が参照カウンタによるからこそ可能なものだ（もちろん、closeやdestroyといったメソッドを規定すれば紳士協定としては可能であるが）。あるいは、MFCからATLへの移行期ということもあってか強型付けの推奨が随分たくさん出てきたりもする。

10.Don't provide more than one implementation of the same interface on a single object. に至ってはCOMを知らなければ意味不明だろう。これは文字通り「1つのオブジェクトが特定インターフェイスの複数の実装を提供してはならない」という意味だが、この規則が生まれるということは、1つのオブジェクトが特定インターフェイスの複数の実装を提供可能だということだ。これはある意味非常にトリッキーなのだが、実際には複数のカスタムインターフェイスをそれぞれデュアルインターフェイスとして実装するシナリオだと比較的簡単にできてしまう。そういうことはするな、ということが書いてあるのだが（COMの交換則が破壊されるからだが）、ちょっと技巧に走り過ぎてあまり意味がない章とも言える。

ちなみに、P.201〜2のエピローグに並べられた箴言を列挙しよう。

・Read the COM specification

仕様書を読め

・Read …… これはいいや。

・Be a skeptic

懐疑的であれ（MSの甘言を鵜呑みにするな）

・Distrust your tools

ツールを疑え

・Learn MTS……これもいいや

・Learn Java

Java may be the future of COM. ... （こいつら知ってたな……）

・Be a part of the COM community

これはそのまま他のインターフェイスセントリクなシステムにも流用できるものだ。たとえばJavaに置き換えてみれば

・Read the Java specification

・Be a skeptic

EJB?

・Learn .NET

・Be a part of the Java community