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

[Kazuya Maebashi <maebashi@xxxxxxxxxx>]

前橋です。

岸田さん:
>> 私はやっぱり interfaceの方が正しいような気がします。
>> 
>…私は、このレポートの場合、変更に強いAPIを作るにはというテーマがある
>ようですので、その限りにおいては abstractクラスを使う選択はいいような
>気がしてます。
>インターフェース（interface でない）で設計していくというのは、なるほど
>と思うのですが、interface にするか abstract クラスにするかはあんまり
>こだわらずに使っていいのかもしれない、どっちも同じ効果だったら、将来
>の拡張に強いタイプを選んでもいいかもと思います。

この場合、「多重継承の問題がないのであれば」が前提ですが、多
重継承の問題があるかどうかは、APIを提供するクラスライブラリ
側で決めることではなくて、インタフェースを実装する側で決める
ことでしょうから、APIがそこを規定してしまうと、汎用性がなく
なってしまうような気がします。

妥協案としては、

(1)interfaceにするけれども、同じメソッドを空で実装した
  abstractクラスを一緒に提供する(イベントアダプタでやってる
  ように)。
(2)メソッドなしのinterfaceを提供し、リフレクション使って無理
  矢理呼び出す(Serializableはこうやってるはず)。

どっちも裏技のような気がしますが...

# ちょっと前に、似たようなこと書いたような気がする(^^;

(2)の技は、これ↓とほとんど同じですが、

>> interface も abstractクラスも使わず、Objectで受けて、メソッ
>> ドの名前だけ決めて、リフレクション使って無理矢理呼び出す...
>> これなら、その名前のメソッドがなければ何もしないようにすれば
>> いいし、名前が衝突しない限り、多重継承の問題も発生しない。完璧!!
>> 
>> ...冗談ですよ。もちろん :-)
>>
>よかった。可読性悪いソース読むのは非常に困ります（困っています）。

とりあえず、Objectでなくてinterfaceで受けるようにすれば、可
読性の悪い部分は、APIを提供するクラスライブラリ側だけにほぼ
封入できる、という点で、あながち冗談とも言えないかもしれませ
ん。もっとも、実装するとき、メソッドの名前や引数を間違えても、
コンパイラは怒ってくれませんが。

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

テレビ会議はともかく、賛同される方いらっしゃいます? > 名古屋の方

7月の週末は大阪行ったり東京行ったりと大変なので、私も東京ま
で行くのはさすがにちょっと厳しそうなんですが、某MLのカラオケ
OFFもあるし... (^^;

# JavaReportの記事は、実は論点が全然違っていたりして。

------------------------------------------------------------
  前橋 和弥                             maebashi@xxxxxxxxxx
  中部ソフトエンジニアリング(株)
    〒450 名古屋市中村区名駅4-10-25(名駅IMAIビル 5F)
    Tel:(052)583-4511(代) 内線 252 Fax:(052)583-4566
------------------------------------------------------------