[jfriends] Re: [jfriends] abstractクラスの方が有効な場合

[Shin <shin@xxxxxxxxxx>]

In article <9906300737.AA13217@xxxxxxxxxx>
Kazuya Maebashi wrote:
>クラスライブラリ側で、いつまでも古いインタフェースを基準にし
>て、適宜チェックしてはダウンキャストということになると、コー
>ドの信頼性に支障が出そうな気もします。
全体に対するコメントですが大幅に略させていただきます.

うーんいきなり準備していない御指摘が...

public void foo(AbstractClass a){
	:
}

というメソッドがあった時、AbstractClassにこそっと新インターフェイ
スが追加された時に、上記のシグネチャを変えなくても、メソッド内部
も型検査の必要がないというわけですね.

新インターフェイスの実装として、空ではなくNonImplementsを呼び元に
通知するような実装をしておけばよいと.

これはそれなりの理由かも...

まあ、でも御指摘中にある通り、interfaceを継承して拡張したとしても
上記のインターフェイス(シグネチャ)は変更しなくてもよいので外から
見たらどちらも同じとゆうことで.
メソッド内の実装がどちらがスマートかということに関しては今回の話
題とは別の問題ですので.
# abstractクラスだってそのメソッドがオーバーライドされているかを
# チェックする処理は通常入りますからね.呼んでみなければオーバーラ
# イドされているかが解らないというのが問題になる場合もあるかもし
# れませんし.
# チェックする必要のないような拡張インターフェイスならオリジナル
# を空にしといて無条件に呼べるんでしょうけど.※

コードの信頼性という点に関して、将来にわたって追加される可能性の
あるインターフェイスが※の条件を満たしていることが保証出来るなら
abstractクラスの方が信頼性が上がる可能性はあります.

しかし、そんな事は分からないわけで、※の条件を満たさないインター
フェイスの場合は、それを実装(オーバーライド)しているかのチェック
にはinterfaceの時以上に気を使わなくてはならず、信頼性が高いとはと
ても言えないと思います.

というわけですごく気を使って特定の条件のみ有用なabstractクラスで
公開インターフェイスを作るよりはinterfaceですねやっぱり.

なんとかしのいだかな?

──────────────────
木下 信＠イデア
──────────────────