上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

今までおいらが思いつかなかっただけで常套手段な気もする…。
…けど他で見ないし…といった感じのメモです。

List の場合は AbstractList 、 Map の場合は AbstractMap のように AbstractXXX と名前の付くクラスがある。これらは、主に各インタフェースの実装補助に使われる。…で、今日、"監視コレクション"を作っていて、他にもメソッドの集中管理のための使われ方がある気がした…。

まず、実装補助について。AbstractXXX はクライアントのための補助的なメソッドを、幾つかのコアメソッドを使って提供する。そのため、実装に必要な作業はこれらのコアメソッドの提供だけになる。

次に、メソッドの集中管理について。

順を追って説明すると、こうした使い方を考えるきっかけは、上でも触れたように監視コレクション(Observable Collection)の実装を考えていた時。監視コレクションとは、要素が追加や削除される時にそのお知らせ(追加イベント、削除イベント)を希望したクライアントに流すコレクションの事。で、この監視コレクション、実は Java SE 6 では提供されていない…。何故提供しないのかと言うと…、

Java コレクション API の設計に関する FAQ
修正されたときにイベントを送出する被監視コレクションを提供しないのはなぜですか。
主に、リソースの制約によります。そのような API に取り組むのであれば、万人に役立つものでなければならず、また長期の使用に耐えるものでなければなりません。このような機能も提供していく予定です。それまでの間、public の API の上にそのような機能を実装するのは難しいことではありません。

という事らしい。…前半はそうか…色々事情があるのか…あんたも大変だな…と思う部分だけど、引っかかったのは、public の API の上にそのような機能を実装するのは難しいことではありません。の部分。ん?そんなに簡単に出切る?と一瞬フリーズ…。

例えば、追加イベントを提供したい場合、追加を行うためのメソッドは複数ある。コレクション本体からの add や addAllメソッド、iterator側からの addメソッド。で、重要なのは、メソッドは他のメソッドに処理を丸投げしてるかもしれないし、それぞれ個別に処理を行っているかもしれない。継承を使うにせよ委譲を使うにせよ、継承先や委譲先の実装は知ることが出来ない(知るべきでない)ため、これらを知ることは出来ない。そのため、どのメソッドを監視すればいいのかも分からない。委譲の場合、全メソッドを監視すればいいんだけど、それも AbstractXXX を一から作るのと同じ位の手間が…。

説明用画像
[ 怠けて監視漏れが出るケース ]

と思ったのもつかの間、AbstractXXX をラッパに使えばいいと気づく!そうすれば、AbstractXXX のコアメソッドを基に全ての処理が構築される。そこさえ監視しておけば、委譲先がどんな処理をしていても気にする必要が無い。めでたし、めでたし。

説明用画像

思うに、こうした使われ方を考慮すると、"インタフェースの完璧な実装をクライアントに提供出来るのなら、AbstractXXX が必要ない" という事は無くなる。たとえインタフェース内のメソッドを完璧に実装したクラスがあったとしても、クライアントはそこに監視系の機能を追加する可能性がある。そうなると、メソッドの集中管理が必要になるため、AbstractXXX が役に立つ。なので、そうした可能性が高い場合は、予めインタフェースと共に AbstractXXX も提供しておくと親切かも…ってメモ。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

スポンサーサイト
Copyright © ふらふら技術者の日記 All Rights Reserved.
Powered by FC2 Blog
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。