[jfriends] Re: 「Javaオブジェクト設計」

[Shin <shin@xxxxxxxxxx>]

Shin＠イデアです.
まあ些細なことなんですがちょっと面白そうだったので...

In article <199811170027.JAA07512@xxxxxxxxxx>
ENDO Yasuyuki wrote:
>>「アクセッサメソッドの1つ1つについてinterfaceを定義するような」ことは
>>あまり意味が無いような気がします。
>
>このメリット、デメリットについて考えてみました。
>
>メリットですが、クラスが多数あるとき、必要なアクセッサーだけを実装すれば
>良いということがあげられるでしょう。
>もし繰り返し現れるパターンがあれば、INameAdress のようにまとめてしまいます。
>また、同書の中に「プロキシーも含めて抽出する戦略」という節(p.87〜)があり、
>INameAdress を実装したクラス Person (人物)と Passenger (乗客) があるとき、
>複数の INameAdress を保持するクラス NameAdressUI は、その保持するクラスが
>Person であっても Passenger であっても変更の必要がありません。
>
>デメリットはやはり interface 数が多くなることでしょうね。
>でもこの interface 群は汎用または準汎用ののユーティリティークラス
>として抽出することが多いので、適切な package としてまとめることで
>管理しやすくすることはできると思います。

私もinterfaceを基本にすることに異論はないのですが、合成interface(?)を
多用すると以下のような混乱が発生する可能性もあるかもしれません.

interface A {
	:
}
interface B {
	:
}
interface C {
	:
}

interface AB extends A, B {
	// ここにメソッドが宣言されていれば話は別
}
interface AC extends A, C {
	// ここにメソッドが宣言されていれば話は別
}
interface BC extends B, C {
	// ここにメソッドが宣言されていれば話は別
}
interface ABC extends A, B, C {
	// ここにメソッドが宣言されていれば話は別
}

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

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

# ※の場合、以下のようにしておけばコンパイルできます.
# interface ABC extends AB, AC, BC {}
# でも色々気を使わなければならないですね


結局設計段階でそのinterfaceが使われる必然性が明確になるように(特に名前
について)十分検討した上で切り出すべきだと思います.
# 例えば紹介された本(読んでないのですが)からの引用にあるIName,
# INameAddressと言った名前からはその役割が推測できませんでした.

使うかどうか解らないけどinterfaceにしとこうということはありますが、ア
クセッサメソッドを片っ端からinterfaceにすることは個人的にはどうかなと
思います.(意味が直感的に分かる名前ならいいけど)

=====================================
mailto:shin@xxxxxxxxxx
=====================================