著作一覧 |
DIContainerを使えば、POJOで組めるので、いまさらCommons Chainは必要ないと思いますが、世の中の流れとして、ロジックをアトミックになるまでばらして、それを後から柔軟に繋いでいくという方向に向かっているのかもしれません。
頭がくらくらしているので、深く考えずにいい加減なことを書いてみる。
発散と収縮は交互に起きるものだと前提する。
構造化プログラミングというのは収縮、オブジェクト指向プログラミングというのは発散(拡散かな?)。これはロジックの位置の問題だ。
今、ある分野(ようはビジネスアプリケーションの世界だ)においては、オブジェクト指向プログラミングのままでロジックの収縮に向かっているのかも。それは業務ロジックが分散しているととってもメンテナス性が低くなることに起因している。だから、ロジックをアトミックになるまでばらすという、それは構造化ですね、という方向が見えているのだ(追記:っていうか、僕にはユースケースがオブジェクトに見えるんですが)。というか、ビジネスアプリケーションというジャンルが、あまりにもそこらに転がっているうえに、一見して面白くもなんともない分野のせいで、まっとうな研究対象とならなかったから一種のブラックホールになっていたからかも知れない。そのため、その分野に特化したうまい方法論というものがきちんと出て来ず、そのため個々の開発者(研究者ではなく。実務者と呼んでも良い)のビジョンが先導するかたちで模索されているからだ。従来であれば、それは企業の枠内でおさえられていたわけだが、そこに一家言ある人たちのオープンな取り組み(ファウラーとかロッドとかを想像すればよろしい。もちろんコンサルとしての宣伝効果とかが裏にはあるわけだろうが、そういった個々の事情とは無関係に、とてもありがたいことである)が姿を現し、それに触発されてより特化した方向での別の取り組みが生まれたり(ひがさんたちのSeasarとか)、そんな状況である。というわけで、考え方としては収縮フェーズに入っているのだが、実装としては拡散フェーズということだ。
そのために、いろんな方法で、それをどううまく片付けるかが現時点でのホットスポットとなっている。AOPをどう適用するかなんていうのがまさにそうだし、DIだってそうだ。コンポーネントの粒度とか、コンポーネントの組み立て(というのはコンテナだ)、全体の枠組みをどう構成するか、配備技術、いろいろだ。したがって、今の時点でたとえばSpringで決まりとか、決めてはいけないわけで、いろいろある考え方のあくまでも現時点での1つの実装例として捉えて、それをどう現実のアプリケーションに適用するかを考えるための手段として見ておいたほうが良いだろう。実装はうつろいやすく、考え方はあまりうつろわない。くだらない個人的経験で言えば、もうCOMを使ってどうこうということはしそうもないが(実装はうつろったわけだ)、そこで得た数々の知見は未だに役に立っている(考え方はなかなかうつろわない)。
どっかで誰かが、リフレクションというのは難しかったらしくてAOPと呼び直したら流行の兆しあり、みたいなことを書いていた。その意味では、オブジェクト指向プログラミングでは、クラスとインスタンスを別物と考える方法より、クラスもオブジェクトな世界のほうが良さそうでもある。というか、メタデータの重要性が確立したということだろう。(この段落はまた全然別のことだな)
としか、今は場所が悪いので書けない。特に反論すべきことはないが、誤読されたままだとおもしろくないので、後でここを埋める予定。
ジェズイットを見習え |
あー、なんだか気持ちいいなあ。
なか変なトラックバックおくちゃったみたいで申し訳ありません。