ひがやすを blog

J2EE勉強会(仮)

etc

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

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

詳細はこちら

• 日時:2005年5月14日(土) 13:00〜17:30(18:00退出)
• 場所:東京都渋谷区代々木4丁目30番3号 新宿コヤマビル12Ｆ 株式会社 FFC　本社事務所　12F会議室
• 地図:http://www.ffc.co.jp/about-ffc/location.html

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

• 氏名
• ハンドルネーム(本名を公開したくない場合)
• 所属（会社名、団体名等）
• e-mailアドレス

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

※氏名のみ必須です

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

宛先のアドレスは

○ without-ejb-owner_at_yahoogroups.jp

× without-ejb_at_yahoogroups.jp

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

Permalink | コメント(0) | トラックバック(0) | 20:24

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

くーす

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

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

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

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

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

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

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

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

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

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

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

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

Permalink | コメント(0) | トラックバック(0) | 17:27