ひがさんのBlogのまとめサイト (7)

wikiroom.com 閉鎖
を読んで勉強するシリーズ第7弾

業務ロジック設計

DIContainerのない時代には、登場人物が増えると、それを管理するコストもばかにできないものになります。徹底的に役割に応じてクラスを分割するという手法が現実的になったのは、やはりDIContainerが出てきたおかげだと思います。
2004-12-23 - ひがやすを blog

今までの観点からするとやりすぎじゃないかってくらい徹底的にロジックを分割していくのは、DIによって簡単に各ロジックの依存関係を管理できるからなのだ、ということなんですね。
また、徹底的にインタフェースを活用していくことで、他のクラスの実装に依存することなく個々のロジックを実装・テストすることができると。
クラス/インタフェースの数は増えるが、その分個々のクラスの仕様/実装はシンプルに保つことができる。これがくーすの大きなアドバンテージとなるわけです。

ただし、やはり増えていくクラス/インタフェースの管理をどのようにするかという実務レベルの課題はでてくると思います。

依存性の管理は当然diconファイルでやればよいです。
ここで言いたいのはそういうことじゃなくて、たとえば1つのパッケージ(ディレクトリ)に50個以上のクラスが格納されていたら、一覧性は悪くなるし、見つけたいクラスがどこにあるのか探すのに迷って、小さなストレスが積み重なっていって、しまいにキーーーーとなってしまうかもしれません。

考えられる工夫は、

適切な数が含まれるようにサブパッケージに分ける
その開発プロジェクトにおけるクラスの命名規約を徹底化して、そのクラスが持つ機能、他のクラスとの関連をぱっとわかるようにする

などがあると思います。改めて言うまでもない基本的なことですね。

あと、Eclipseであれば「Ctrl+T」のクイック型階層などを使って、簡単にインタフェース-実装間をいったりきたりできます。かなり便利です。

くーすの基本的な考え方は、ビジネスモデルをシミュレートして設計・実装モデルを作ることです。余分なギャップをできるだけなくそうと考えています。
2004-12-31 - ひがやすを blog

業務分析の結果を更に複雑にこねくりまわすことなく、そのまま設計/実装に反映できるといいですね。
ついつい、やんなくてもよい余計な抽象化をはじめてしまうことが多々アリ。反省。

- - -

今日はここまで。明日は「ODBの幻想」から。
明日でくーす編は終わるかなー？