[ooaa main]  [object pasta2]   [essence] (旧blogはこちら)  [flickr]  [myspace]  [View Eiichi Hayashi's profile on LinkedIn] 

時代によるフレームワークの責務の違い

以前のフレームワーク開発の責務は、オブジェクト指向がわからなくても開発できるということだった。 大量のCOBOLプログラマを1〜2週間Javaの研修を行ってプロジェクトに投入なんていう前提だったら、当然の選択で、コンポーネント指向な、設計方針になってオブジェクト指向まったくわからなくても、COBOLとおなじ頭で開発が可能なフレームワークの必要性は高かったわけだ。

気がつくと、多かれ少なかれ、ちまたのフレームワークは同じようなコンセプトのものが多くなった。

そこで、逆にオブジェクト指向がある程度わかるプログラマの方が多い場合のフレームワークの責務とは何だろうということを考えてみたい。つまりある程度オブジェクト指向がわかる人にとってわかりやすくて、実装しやすい環境を提供するのを責務とするフレームワークとはなんだろうかという問い。

やはりキーワードはDIコンテナとアスペクト指向ではないかとおもう。

古典的なドメインリッチな実装で問題になる点は、一つのクラスの責務が大きくなりすぎる傾向であると思う。 それはある意味、直行する概念の実装までドメインオブジェクトに書いてしまっているからと言えるのではないだろうか。 純粋なビジネス領域だけを意味した抽象的な構造を記述できれば、それはシンプルで美しく、可読性の高い実装足り得るのではないだろかという期待がある。

現実のアプリケーションは、純粋なビジネスの構造を書く機会はあまりなくて、どちらかというと、泥臭い画面制御やらSQL を含むDB制御ロジックを大量に書かなければならない。

DIコンテナはPOJOを、プログラムのシンプルな単位とする出発点を与えてくれたと思う。 課題は下記のキーワードにあたるリソースたちを、シンプルでわかりやすい構造でどう関係づけられるかにかかっていると思う。

  • 抽象度のレベルの違うオブジェクト間のシームレスな連携
  • 設定情報の廃止あるいは最小化
  • 静的な構造情報
  • 永続化のためのロジックの隠蔽

これらの統合は、アスペクト指向だけでは十分ではない。