[jfriends] Observable,Observerへの応用

[ENDO Yasuyuki <yasuyuki@xxxxxxxxxx>]

>class Hoge implements A, B {
>//class Hoge implements ABC {　でも同じ※
>	public static void main(String[] arg){
>		test(new Hoge());	// ←エラー

このエラーは、複数で開発している場合などは起こりそうですね。

>	void test(AB ab){

この引数を java.lang.Object にしてしまい、instanceof で検査する戦略は
いかがでしょう。

>みたいなのがあまり多くなると、そのスーパータイプ達を実装している人が、
>それらを合成したもの(サブタイプ)で実装していなければならないといったこ
>とに気づくのが遅れる可能性があるんじゃないかと.

本来、class Hoge implements A, B { みたいなパターンが繰り返し出てきたら
それらをまとめて interface AB extends A, B みたいにして抽出して
class Hoge implements AB と書き換えていく戦略ではないかと解釈しています。

>結局設計段階でそのinterfaceが使われる必然性が明確になるように(特に名前
>について)十分検討した上で切り出すべきだと思います.

私もこれは賛成です。

># 例えば紹介された本(読んでないのですが)からの引用にあるIName,
># INameAddressと言った名前からはその役割が推測できませんでした.
>
>使うかどうか解らないけどinterfaceにしとこうということはありますが、ア
>クセッサメソッドを片っ端からinterfaceにすることは個人的にはどうかなと
>思います.(意味が直感的に分かる名前ならいいけど)

私は 1 アクセッサー 1 interface の戦略にびっくりしてそればかり強調した
のが悪かったかも知れません。Coad が前掲書で書いた例題は適切なものだったと
思います。

INameAdress とはちょっと文脈が異なる例ですが、
例えば５章の「通知を利用した戦略」で、
java.util.Obserbable / Observer を使うかどうかという問題について、
「継承に適した例では無い」と判断した Coad は、

public interface IObserver {
  void update(Object theObserved, Object changeCode);
}

public interface IObervable {
  void addIObserver(IObserver anIObserver);
  void deleteIObserver(IObserver anIObserver);
  void deleteIObservers();
}

という２つの interface を書いて Observable, Observer を実現しています。

この応用で、Repeater (中継者) を間に挟んだ例を扱い、

public interface IRepeater extends IObservable, IObserver {}

という interface を導入しています。
------------------------------------------------------------------
遠藤靖之 (えんどう やすゆき) <yasuyuki@xxxxxxxxxx>
http://www.freepage.total.co.jp/jfriends/ (Java互助会ホームページ)
株式会社タイムインターメディア 情報通信サービス部 TEL 03-5362-9009
〒162-0065 新宿区住吉町3-11 新宿スパイアビル8F    FAX 03-5362-9008