Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2005-05-10

J2EE勉強会(仮)

without EJB読書会の次のステップとして、J2EE勉強会(仮)を5/14に行います。agendaは以下のとおり。

  • S2JTA、S2DBCPのソースを読んで、JTAとコネクションプーリングについて理解する
  • JSFを基礎から応用まで理解する。第一回は、JSF VS Struts

詳細はこちら

参加したい方は5/12(木)まで(23:59ギリギリOK!)に

を without-ejb-owner_at_yahoogroups.jp 宛に送って下さい。

※氏名のみ必須です

※本名を公開したくない場合は、HNも併せてお願いします

宛先のアドレス

○ without-ejb-owner_at_yahoogroups.jp

× without-ejb_at_yahoogroups.jp

です。お間違いのないように!

構造化分析・プログラミング

「良くない設計」や「良くない実装」をしてしまわないための一番の近道は、「構造化分析手法」の適用だと考えています。基本的に規模が大きければ大きいほど、携わる人間が多ければ多いほど、そして仕様変更が入る確率が高ければ高いほど、構造化分析および構造化プログラミングがなされていないと手詰まりになります。

2005/05/09 日記: オブジェクト指向レス開発

私は、はっきりいって構造化プログラミングは、好きではないし、有害とさえ思っています。なぜなら、トップダウンでメソッドを詳細化していく方法は、より抽象度の高いメソッドがより具体的なメソッドに依存することになり、変更が入ったときにその影響を受けやすくなってしまうためです。

オープンクローズの原則は、最も守らなければいけない重要な原則です。仕様の変更はコードを修正するのではなく、コード追加で対応できなければならないのです。

OCPを守るために、くーすでどうしているかというとロジック(メソッド)は常にインターフェース経由で呼び出すようにします。あるロジックが別のロジックを呼び出す必要があった場合、DIコンテナによってロジックオブジェクトをDIしてもらい、それを利用するのです。

ロジックごとにインターフェースを用意します。ただし、ここでいっているロジックは、ユーザから見てレビューできないようなものは含まれません。

仕様に変更が起きた場合には、そのロジックオブジェクトインターフェースを新しい仕様で実装しなおし、それをDIしてもらえばいいのです。

仕様変更によって利用する側が影響を受けることはありません(もちろんインターフェースが変わらない範囲でですが)。

業務ロジックを分析するのに構造化分析を使うのは、望ましいことだと思っています。なぜなら、私たちが業務をこなすとき、一定の手続きに基づいているはずで、それは構造化されているはずだからです。

くーすの最も根本的な考えは、現実により近いモデルが良いモデルだということです。そうすると、仕様変更が起きたときも、どこを修正すればいいのかが明確で、仕様変更に見合う分の修正をすればよいからです。

私たちが行う業務というのは、伝票などの紙と業務手順(マニュアル)で成り立ってますから、それをそのままモデルに落とすのが良いでしょということです。

ちなみにドメインモデルだと特定のメソッドだけ仕様変更したいなんてのはOCPを守って行うのは難しくなります。全メソッドをStrategyパターンで切り替えられるようにするのは現実的でないしね。

takakuntakakun 2005/05/11 18:25 j2ee勉強会(仮)ですけど... 会議室のセキュリティ関連で事前の参加登録が必要です。当日いきなり来ても入れないのでご注意ください。上でそこら辺りに言及されてなかったので念のためコメントです。