[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


お久しぶりです.Javaじゃない仕事が忙しくて読書会等参加するパワーがな
くて申し訳ないです.
# 横浜なら...実はServletBOFにでてみようと思っとりますが.
In article <199906161736.CAA05620@xxxxxxxxxx>
Toru Takahashi wrote:
>AbstractクラスとInterfaceの使い分けに関する記事です。Interfaceでは、
>既に定義して使われている、あるInterfaceの定義にメソッドを追加した場合
>このInterface定義を実装していたクラスは全部エラーとなってしまう。
>＃このエラーは、コンパイルエラーというより実行時エラーの意味だったと
>＃思いますが、詳しくは覚えてません。
>
>例えば、java.awt.LayoutManagerインタフェースにメソッドを追加したかった
>が、その場合LayoutManagerを実装しているクラスがエラーとなってしまうので
>LayoutManager2という新しいインタフェースを定義した。
>この問題は、Abstractクラスを使うことによって避けられる。あるときAbstract
>クラスにメソッドを追加しても、Abstractクラスを継承していたクラスには
>エラーとならない。
>＃これは本当かどうか未確認です。
>
>多重継承の問題がないのであれば、InterfaceよりもAbstractクラスを使う方が
>betterという結論を出していました。
>
>この記事は、確か"Durable API"という連載のもので、安定したAPIを設計する
>テーマに沿っています。今回は、一度定義したAPIを変更する場合、Interface
>かAbstractクラスかどちらがよいかという話題です。

最初はそんなものなのかなって思ってましたが、これってinterfaceを継承
すればいいだけじゃないです?って上のメモに既に書いてありますが、
LayoutManager2なりの拡張された新しいinterfaceを用意するほうが正しい
というか.
「abstractクラスを使うことによって避けられる」と言っているのが、何を避
けようとしているのかいまいち見えてきませんね.

私は余所でinterfaceにインターフェイスを追加したら全実装クラスを直さ
なければならないからどうのこうのと言った覚えがありますが、普通は公開
されたinterfaceにメソッドを追加するよりはそれを継承した新たな
interfaceを作りそうなもんだと後になって思いました.

公開する(実装を含まない、としときましょう)インターフェイスをabstract
クラスで提供しておくことで考えられる利点は・・・うーん全部interface
でも普通に解決できそうな気がしてきました.

あえて言えば、同一のinterfaceとして拡張がしづらいという、上に挙げら
れている点ですが、abstractクラスだったからといって空のメソッドを増や
して「インターフェイスを拡張した」と言ってみても、そのインターフェイス
を実際に利用できるのは、それを継承しているクラス群の中の新インターフ
ェイスの実装を行って再コンパイルを行ったものだけなわけですから、
interfaceを継承した場合と手間は変わりません.
# 新interfaceをimplementsするように書き換えてインターフェイスの実装
# も行うという手間ですね.
# interfaceの名前を決めるのが面倒＋implements節を書き換えるのが嫌だ
# ということなのかもしれませんけど...

逆に問題点として、多重継承できないというのも既に挙げられていますが、
やはり前橋さんも挙げられていますが、スペルミス等で正しくオーバーライ
ドできていなくてもコンパイラが教えてくれないというのは大きな問題点だ
と思います.

というわけでやっぱり結論は、今のところabstractクラスは実装の委譲コー
ドを書く手間を軽減すると言った利便性以外の、(要は設計方法として)明ら
かにabstractクラスの方が良いといえるようなケースにお目にかかったこと
がありません.ということにしてみます.
御指摘があればお答えする準備はあります...がいつかは分からない..

# やっぱり本を見ていないから若干の不安はありますが.

--
木下 信＠イデア