[jfriends] Re: [jfriends] Re: 『Java Report』？の記事

[YUKIE Kishida <yukie@xxxxxxxxxx>]

岸田です。

Kazuya Maebashi さん wrote: 
> # 件の Java Reportの記事は、まだ読んでません。(^^;
> 
私もまだ読んでないというか…買いに行ったのですけど、なかったので、今度
の読書会で読みたいと思っているのでした。

> 岸田さん:
> >> AbstractクラスとInterfaceの使い分けに関する記事です。Interfaceでは、
> >> 既に定義して使われている、あるInterfaceの定義にメソッドを追加した場合
> >> このInterface定義を実装していたクラスは全部エラーとなってしまう。
> >> ＃このエラーは、コンパイルエラーというより実行時エラーの意味だったと
> >> ＃思いますが、詳しくは覚えてません。
> >>
> >実行時エラーのような気がします。
> 
> ええと、この場合、安定した「API」を設計する話ですから、クラ
> スライブラリをクラスファイルで提供するとして、それを使用する
> APにどう影響を与えるか、ということですよね。
> 
そうだと思います。

> 「コンパイル時エラー」以前に、そもそもコンパイルしないことが
> 前提なんじゃないかと思ったんですけど...
> 
> # 完璧に勘違いしてますか? 私。
>
さあ？ 私も勘違いしているかもしれないのですか、そのクラスライブラリも
それを使う自分のクラスもコンパイルしないことが前提だとは思いました。
それでクラスライブラリが入れ替わった場合を言っているのかなと思いました。
＃読んでないので分からないのですけど…。
 
> コンパイルするのなら、implementsしていながら全メソッドを実装
> していないクラスは、コンパイルエラーになると思うのですけれど。
> 
そうですね。

> 実行時エラーだとしたら、ロード・リンク時にはねてくれるのが親
> 切だと思いますが...
>
そう思いますけど…。
 
> >> この問題は、Abstractクラスを使うことによって避けられる。あるときAbstract
> >> クラスにメソッドを追加しても、Abstractクラスを継承していたクラスには
> >> エラーとならない。
> >> ＃これは本当かどうか未確認です。
> >>
> >追加したメソッドを Abstract にしないで空のメソッドでも書いておけばいい
> >ということなのかもしれませんね。
> 
> でしょうね。
>
それだけの問題ではありますが、interface の場合はそうはいかないということ
で…。
 
> >> 多重継承の問題がないのであれば、InterfaceよりもAbstractクラスを使う方が
> >> betterという結論を出していました。
> >>
> >なんとなく納得してしまうのですが、これは、たぶんコードさんは反対する
> >お話かもと思いました。
> 
> interface も abstractクラスも使わず、Objectで受けて、メソッ
> ドの名前だけ決めて、リフレクション使って無理矢理呼び出す...
> これなら、その名前のメソッドがなければ何もしないようにすれば
> いいし、名前が衝突しない限り、多重継承の問題も発生しない。完璧!!
> 
> ...冗談ですよ。もちろん :-)
>
よかった。可読性悪いソース読むのは非常に困ります（困っています）。
 
> 私はやっぱり interfaceの方が正しいような気がします。
> 
…私は、このレポートの場合、変更に強いAPIを作るにはというテーマがある
ようですので、その限りにおいては abstractクラスを使う選択はいいような
気がしてます。
インターフェース（interface でない）で設計していくというのは、なるほど
と思うのですが、interface にするか abstract クラスにするかはあんまり
こだわらずに使っていいのかもしれない、どっちも同じ効果だったら、将来
の拡張に強いタイプを選んでもいいかもと思います。

前橋さんも名古屋で読書会同時開催するとか？…テレビ会議できるといいで
すね。

------
岸田ゆき枝
yukie@xxxxxxxxxx