我ながらタイトルを見て、世間からどれだけ遅れているんだ、と思わずにいられませんが、新しい言葉に飛びつく芸風(?)でも無いのでよしとします。

• http://itpro.nikkeibp.co.jp/article/COLUMN/20080620/309086/?ST=develop&P=3
• http://docs.sun.com/app/docs/doc/820-4867/ggnxo?a=view

この辺のサンプルを見ていて思ったことです。

伝統的なJavaの世界では、型の継承による振る舞いの強制が、世界を支配するルールでした。上のサンプルコードは、このルールから解き放たれています。

POJOと言うと、DI(dependency injection)コンテナと一緒に語られることが多いと思います。ちなみに、ぼくはDIが結構好きです。

DIは技法としては新しいですが、伝統的な価値観の延長線上にある技術だと思っています。DIが実現するのは、インターフェースに対してプログラミングせよ、という良く知られた標語です。抽象型(Javaではインターフェース)への依存だけを持つPOJOは、具象型(Javaでは具象クラス)への依存から解放されます。実行時にDIコンテナ(フレームワーク)が具象クラスへの依存を解決(注入)します。DIコンテナが注入するのは具象型への依存であり、抽象型への依存は依然としてコードに残ったままです。つまり、型の継承による振る舞いの強制、というルールは残ったままです。

上のサンプルコードのアノテーションが指定する振る舞いは、従来の型よりも粒度が荒い、より上位な概念、プロトコルやアーキテクチャとでも呼ぶべきレイヤです。

型の継承から離れた振る舞いという意味では、(よくRubyのまつもとさんが書く)ダックタイピングがあります。あれはあれで別にいいのですが、メソッドのシグニチャが一致しているだけ、という世界には危うさを感じます。危うさというのは、コードが複雑化、巨大化した時にきちんと機能できるか、という懸念です。個人的には、ダックタイピングのような緩い世界は不安です。型に対して明示的にプログラミングしている方が安心できます。要は、静的型言語の方が安心できる、と言っているだけですが。

型の継承は、例えそれが抽象型であれ、依存性が発生するという点で窮屈な部分があります。また、粒度が低いので、少し大きな振る舞いや構造を記述するのに、型の記述を積み上げていくのは面倒です。この面倒さに対し、Railsなどでは、規約による簡略化をしています。規約による解決は、暗黙的すぎてあまり好きではありません(Railsは慣れましたが)。アノテーションによる解決は、適度に明示的で、適度に緩いので、上位構造を指定する手段としては良い気がします。