| 著作一覧 |
しかし、CORBAとかCOMとかだとIDLで定義したインターフェイスと実装はイヤでも分離されるわけだが、それが正しいとJ2EEな人達が言うような時代になるとは思わなかったといえば思わなかった。
It's best to program to interfaces, rather than classes.
思えば、ATLとかでCOMのコンポーネントを作る場合、最初はWizardでテンプレートを生成するわけだが、次にやるのは、IDLにメソッドを定義することだ。helpstring属性を記述したりしながら。
で、midlでヘッダを生成して、それを実装クラスのヘッダにコピペして、=0とかを削除して、次に編集したのをソースにコピペしておもむろに実装に取り掛かるわけだが、ほとんどこういう作業になるってことなんだろう。
最初にinterfaceのソースをJavadoc書きながら作って、それをコンパイルしてからおもむろにclassの実装に取り掛かるということだ（少なくてもEmacsで記述する場合には。もしかしたらEclipseとかだとVBでCOMのコンポーネントを作るみたいに、いきなり実装するとpublicメソッドを抜き出して勝手にinterfaceを作成するとかだったりするのかも）。
ということはだ。
あれだけクソだ、カスだ、と言われているVB6のOOPだが、あれでも十分ってことになる。少なくてもインターフェイス継承は可能なんだから（実際、VB6でストラテジパターンというのはやっている）。
かくして、ますますOOPという言葉が意味するものが人によって全く異なってくるということでもある。
例）
A「OOP、もちろん経験ありますよ」
B「ほー、でどんな言語で？」
A「VB6です。」
B「（ニヤリ）」
A「やっぱーり、違いますかねぇ（卑下）」
B「うーん、あれはねー。やっぱりJavaとかじゃないとねぇ、OOPとは言えないんじゃないですかねぇ」
でも、Aはストラテジパターンで業務ロジックを実行するアプリケーションを組み立てていて、Bは継承地獄でのたうっているという罠とか。
#ogijunさん、一昨日は失礼しました。思い出しましたというか、確認しました。
ジェズイットを見習え |
インターフェースと実装の分離は大事ですが、ソースで分離を強制されるのはちょっと嫌です(C++のヘッダみたいに)。<br><br>要は頭の中でインターフェースだけを相手にできればよいので、物理的に分離してメリットがない限り、一緒でもいいという選択があるのは楽だと思います。<br><br>そこがJavaの良いところでもあり、OOを解りにくくしている原因だと思いますが．．．
良くわからないんですが、interfaceとclassを同一ソースに書いているのですか？
え、VB6のOOPって評判悪いんですか？ あれってとっても高尚なものだと思ったんですが(実装継承が出来ないという点で)。
@itの会議室とかたまに覗いて見ると、VBはOOPLじゃないっていうような書き込みを結構、見かけますからねぇ。
わかりにくくてすみません。<br>ソースにclass ClassAがあったとしたら頭の中だけでinterface ClassAとその実装に分離すればよいでしょうという意味です。
ああ、なるほど。ただ、それならば、別にC++のヘッダを引き合いに出すことはありません。ヘッダは必須ではないからです。（IDLについては別。メタデータを持たない言語に対しても透過性を確保するために、別途メタデータの記述が必要になるから）<br>ちなみに、僕はその頃のクセみたいなもので、最初にインターフェイスを記述してから、あらためて実装に入るのが好きです。<br>更に付け加えるとテンプレートメソッドパターンも比較的使用するので、インターフェイス関係ない伝統的なOO実装も好きだったりします（とは言え、最近はそういうのは書かないなぁ）。
インタフェース重要！っていうのは、Coad先生が昔からひたすら力説してた気が。<br>＃「J2EEな人たち」を誤読しているかも・・・。