プログラムの柔軟性とソースの可読性はトレードオフ

いまいちMacが使いこなせないため、開発はちょっとおいといてブログを更新してみる。^^);

＃control+クリックでポップアップメニューとかめどい。ショートカットキーでいけるんだろうか。
＃ファイルのリネームもWindowsならF2でいけるのに、Macだとマウスをピンポイントに合わせてクリックしないといけない。
＃いい方法があるのかな。

つくづく思うのは、プログラムの柔軟性とソースの可読性はトレードオフだということ。

例えばnew演算子を使わないで、設定ファイルからクラス名を取得して
リフレクションAPIを使ってインスタンス生成するいわゆるAbstract Factoryパターンがある。
この手法を使えば、設定ファイルの変更のみで再コンパイルすることなく実装クラスを変更することができる。

適用例としては、commons-loggingかな。

上記の方法の難点はソースの可読性が低くなるということ。EclipseでF3押してメソッドの中身をずっと
追っていって最終的にインターフェースにたどり着いたときのアノがっかり感。
いやCtrl+Tすればいいじゃんという声も聞こえてきそうですが。。。
それ以外にも設定ファイルはコンパイラのチェックを受けられないので、実行してみないとわからない。
ツールで検証できればまだいいですが。

いや確かにフレームワークだったら上記のようなことは必須だと思うんですよ。

ただフレームワークにのっかるアプリケーションを開発しているときに柔軟性を求めすぎるのはどうかということ。

もちろん、DBサーバのIPアドレスのような環境依存のものは外だしにすべきだと思う。

ただ、実装クラスに関する情報まで、外だしにするのはどうなのかなあ。

実装クラスを変更することなんてまず無いんだから。

多分柔軟性マンセーの流れはStrutsあたりから出てきたんじゃないのかな。
設定ファイル以外の例でいえば、ActionとLogicを分けましょうっていうのも柔軟性のひとつ。
この流れで何でもかんでも分割していくとファイル数が膨大になって、場合によっては少しの修正なのに多くのファイルを
いじらないといけなくなってしまう。これはかなりストレス。

僕自身はこの流れを（何も考えずに）受け入れていたけど、心のどこかで何か違和感があったのも事実。

設定ファイル、インターフェース、抽象クラスを使うことにどれだけメリットがあるのか正直いってわからなかった。
（いまでも正直わかっていない）

この流れがSpringの設定ファイル地獄といわれているものでピークに達して、最近は揺り戻しが起きている気がする。

Seasarのプロダクトを見たり、id:ppoiさんにいろいろ教えてもらったりしているうちに、
やはり「あるべきものはある場所に」というコンセプトが大事なんだと思った。

アノテーションもこの揺り戻しのひとつなんじゃないかな。
フレームワーク固有のアノテーション付きのクラスをPOJOといったりするのはちょっと違和感があるけど。^^);
なんとなく僕のイメージのPOJOはJAVAの標準APIでコンパイルできることなので。

それにしてもSAStrutsのActionなんてホントシンプルだなー。

うーん、なんかいつもながらにまとまりの無いエントリだな。^^);