digesterはType2っぽい

JoeyはXMLのマッピングにtoruqe-genのマッピングとは別の方法を採用しています。
toruqe-genはSAXをそのまま使っているのに対して、Joeyはjakarta-commonsのdigesterを使っています。
なんでそんな部分を変更してしまったかというと、単にSAXのハンドラは読みにくいからです。
いちいちソースコードを追いかけるのが大変なので、digesterに置き換えました。

これはdigesterがXMLの要素をオブジェクトとマッピングするときに、要素の属性とオブジェクトのプロパティを名称で自動的に結び付けてくれるため、SAXハンドラを使った場合のこの要素のこの属性はこのオブジェクトのこのプロパティに値を代入する、というような処理を省けるためです。
これは非常に強力な機能で、属性とプロパティ名が異なることさえなければ非常に扱いやすいです（そんなこと稀だと僕はおもうのですが、属性名が異なってしまった場合でも、エイリアスのようなプロパティを作ってあげればOKです）。デバッグは面倒なこともありますが、後々メンテナンスすることを考えるとやっぱりdigesterを使った方が便利だと思っています。

しかし、要素名と対応するBeanのクラス名を登録しておくだけで、自動的にそのBeanのインスタンスを生成してくれるのは非常に便利ですが、final好きの僕には問題があります。そう、デフォルトコンストラクタを使用しなければならないのです。例えばXMLに記述されるオブジェクトのプロパティの中にはインスタンスが要らなくなるまで値が変わる必要がないものがあります。final好きな僕としてはこれらを是が非でもfinalにしたいところなのですが、digesterの便利さの前ではfinalを諦める他ありません。

こんなことを考えていたら、これってIoCのBeanの生成と同じことだと気づきました。
で、僕はdigesterにType3の機能が（も）欲しいんだと気づいた次第であります。

あ、考えてみれば属性にメソッドの呼び出しが関連付けられるんだから、コンストラクタだって関連付けられるじゃん。自分でそういうRuleを作ってあげればいいだけな感じがしてきたぞ。
（いやでも、digesterはスタックでオブジェクトを保持しているだけなので、コンストラクタの引数に他のオブジェクトを渡すのって難しい。作り終わったオブジェクトはスタックから出されるはずだから。digesterがオブジェクトの関連まで管理し始めたらIoCコンテナもどきになっちゃうよ。・・・・それはそれで便利かも。）

でもJoeyのスキーマ関係のモデルは、基本的にすべてTorque-genのモデルを継承しているからそれだけじゃダメだな。finalにできるのは、自分で拡張した部分だけですな。それにfinalにしたい部分って結構数がある。これをコンストラクタがーっとに並べるのって、僕的にはいまいちな感じ。