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

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

設計

コントロール分析 2004-07-29 - ひがやすを blog

くーすで、ロバストネス分析からコントロールクラスを抽出する方法。
以前よりちょっと手直しが入ってるそう。

ユーザ機能分析 2004-07-31 - ひがやすを blog

FDDというのが良く出てきますね。Feature Driven Developmentですかね。
余裕があったら勉強してみようかな。
ここに簡単な説明が→Technologic Arts Incorporated | アジャイル開発。

Stateless BusinessLogicパターン。
これは、変更が多く、複雑な業務システムを開発するための銀の弾丸だ。しかし、幻ではない。
2004-08-05 - ひがやすを blog

今では幻になったくーす本構想。銀の弾丸、言いきっちゃったよぅ。

コントロールのシナリオをシーケンス図に書くときにメソッドをアトミックなものになるまで分解するのですが、その指針を上げておきたいと思います。

開発言語的な要素が出てはいけない

何をやっているのか意味不明なメソッドは作ってはいけない

幾つかの処理の塊に名前を付けることができるなら、別メソッドに切り出すべし

条件判定部分は別メソッドに

繰り返される部分は別メソッドに

2004-08-19 - ひがやすを blog

Dependency Injectionパターン 2004-08-21 - ひがやすを blog
DIとStrategyパターン 2004-08-21 - ひがやすを blog

くーす本の中で、DIContainerあるいはAOPの出現によって、GoFのデザインパターンがどのように実現されるのか、あるいはなくなるのか、まとめたいと思います。
2004-08-21 - ひがやすを blog

これ、すごい読みたい。けど、確かくーす本企画って頓挫したんだっけ？
読みたいなー。

今、目の前にいるユーザのニーズを必要最小限で満たすことが正解なのだと。
過去の経験は、ユーザのニーズを引き出すための引き出しに使えば良いのだと。
http://d.hatena.ne.jp/higayasuo/20040822#1093145015

キャッシュ

Logic層でキャッシュが有効なのは、結果を導き出すために必要なデータが不変で、処理そのものには時間がかかる場合でしょう。
普段そのような状況にあまり出会わないような気がしますが、であったとしても、アスペクトで処理せずLogic層に直接処理を記述した方が良いと思います。
〜(省略)〜
ショートキャッシュはリスクの少ないキャッシュです。
トランザクション中なので、他のトランザクションで同じデータに更新が入る場合も、RDBMSなどのリソース層の人がうまく制御してくれます。
しかし実際は、トランザクション中に同じデータにDaoを使ってアクセスすることはあまりないでしょう。
〜(省略)〜
ロングキャッシュはいろいろ難しいことが多く、まだこなれたものになっていません。
成熟しているRDBMSのキャッシュに任すのが無難で現実的でしょう。
〜(省略)〜
最後は、データそのものであるEntity層でのキャッシュです。
Entityが他のEntityと関連がある場合に、getterメソッドでキャッシュをおこないます。
POJO(特定のAPIに依存していない普通のJavaのオブジェクト)を使う場合、getterメソッドにアスペクトを使ってDaoを埋め込むことになるでしょう。ショートキャッシュなら有効だと思います。
2004-08-08 - ひがやすを blog

サービス指向

開発者の目線ではなく、ユーザにとって価値のあるサービスを提供する
2004-08-09 - ひがやすを blog

くーすの本質はサービス指向だと思ってます。

インターフェースと実装を分離する

インターフェースが分かっていれば実装はきにしなくていい

依存性を排除する

サービスを疎結合にする

これってサービス指向の本質だと思います。
上記を実現するために

Dependency Injection

Stateless BusinessLogic

パターンがあるわけです。
〜(省略)〜
akon 『はい、そう思います。オブジェクト指向とサービス指向はhowとwhatのように、ベクトルが違うと思ってます。どのように実装しますか。オブジェクト指向で実装します。なにを開発しますか。サービスを開発します。つまり、開発者にはオブジェクト指向、ユーザにはサービス指向です。』
2004-08-09 - ひがやすを blog