« RESTful Web Applicationの可能性 | メイン | RESTfulアプリケーションとCookie »
2005年06月23日 (木)
AnnotationとPOJO [テクニカル]
『設計と実装の狭間で。 - AJOってどうよ？』を読んで。ちょっと極端な考え方かもしれませんが。
POJOという言葉が、現在どういう意義・意図を持って使われているのかが重要。言葉の発祥としてはどうやらEJBのカウンター的概念として作った言葉らしい（Martin Fowler's Blikiなど参照）。よって複雑さの解消という意義ももちろんあるだろう。しかし、現在では主に「実装依存性の解消」という意義がクローズアップされていると考える。これはTDDやDIにもつながる考え方である。
簡単な例だと、「ライブラリのような外部の特定クラスからの継承をしない」というのがある。クラスの継承は基底クラスへの依存性を生む。つまり外部のライブラリの実装に強く依存したクラスとなってしまうからだ。だからといって、継承しないといっても、極端な例を挙げると、
class Foo
private bar;
public Foo() {
bar = new BarImpl(); // BarImplは外部ライブラリの実装クラス
}
...
}
こんなことをしていると完全にダメだ。BarImplという特定の実装クラスに依存しているからである。これでは結局testabilityが失われ、POJOとしての意義をなさないのではないかと考える。ここまでくるとPOJOという言葉がふさわしいかどうかわからない。だがそういう意義をもって使われている言葉だと私は理解している。
本題。Annotationをつけることは、実装依存性と全く関係がない。「オブジェクトが期待される全ての機能」とは、クラスにコードとして書かれているものがすべてであって、Annotationによって実現される付加的機能はあくまでAnnotationを処理する外部のライブラリによって実現されるのである。そしてそれらの間には（強い）依存性はない。よって、AnnotationをつけたクラスのオブジェクトはPOJOと呼んで全く差し支えない。
投稿者 4bit : 2005年06月23日 11:54
トラックバック
このエントリーのトラックバックURL:
http://www.4bit.net/x/mt/mt-tb.cgi/66