ひがやすを技術ブログ

電通国際情報サービスのプログラマ

金融市場で力を発揮する電通国際情報サービス

etc

http://www.thinkit.co.jp/free/article/0701/23/1/
なぜかうちの会社の紹介。ちょっと誉めすぎな気もするので､話半分に読んでください。一点気になったのは､「優れたフレームワークを提供できたISID」の部分。このフレームワークという言葉は、Seasar2を指しているのではなく､「オープンソースを使ったトータルソリューション」を指しているのだと思います。念のため補足。

フレークワークに依存しないっていうけどさ

etc

アプリケーションのコードは、フレームワークに依存せずに済ませられるなら、それに越したことはありませんが､依存して楽できるなら別にいいんじゃないのというのが私の考え。もちろん、フレームワークを後から取り替えることが前提の場合は別ですが､そんな開発聞いたことないし。
ほとんど起こらないだろうということに工数をかけるのはどうかなぁと思います。
同じことがデータベースにも言えます。特定のデータベースに依存するSQLを書かないのに越したことはないが､方言やストアドプロシージャを使えば楽できたり、速度が速くなるならできるだけ利用したほうが良いと思います。

POJOマンセーっていうけどさ

etc

単体テストコードの生産性を第１に考えるとすると，フレームワークやアプリケーションコードに対してある程度余計な工数をかけてでも，フレームワークに依存していないアプリケーションコード（≒POJO）で書けるようにした方がトータルでハッピーではないかと。

テスト第一は全面的に同意。
POJOのメリットは、

  • 特殊な環境に依存しないのでテストがしやすい。
  • 余分なAPIをわざわざ覚える必要がない。

にあると思います。そもそも、POJOって何って話は､過去に何度もされていますが､特定のAPIに依存しないというより､「特定のクラスやインターフェースを継承したり実装する必要がない」くらいのほうが、現実的でしょう。今では､アノテーション使いまくりでもPOJOだといってますからね。
仮に特定のクラス(API)に依存したとしても､そのクラスがPOJO、あるいはインターフェースなら特に問題なく､テストのしやすいPOJOだといっても問題ないと思います。
特定のクラスを継承してもテストしやすければいいじゃんという意見もあるかもしれませんが､継承ベースでテストしやすくするには､かなり注意深い設計が必要です。それが可能なくらいの設計力があるなら､継承に頼らずに済ます方法を考えるのも十分にできるでしょう。
POJOとは、

  • 特定のクラスやインターフェースの実装を前提としない。
  • 依存しているクラスもPOJOもしくはインターフェース。

ということで良いのではないかと思います。それによりテストしやすいという最大のメリットを享受できます。