[jfriends-ml 12278] Re: 「デザインパ ターンとともに学ぶオブ ジェクト指向のこころ」 を読む会第３回エントリ

["Yuji Okazawa" <yujiorama@xxxxxxxxx>]

岡澤です．

本日はお疲れ様でした．
議事録を送付します．
ラフなメモに近くなってしまったのですが，ご容赦ください．


平成18年3月11日(土)
「デザインパターンとともに学ぶオブジェクト指向のこころ」第 3 回議事録
時間：10:00 - 17:00
場所：高津市民館第4会議室

参加者 (敬称略)
  高橋(徹)，遠藤，大崎，村山，高橋(良)，小松，岩室
  吉本，岩永，根本，小棚木，高橋(智)，中島，岡澤，上條
  奥，金井
読み手 (敬称略)
  岩室，吉本，岩永
書記
  岡澤

pp. 132
第 9 章 Strategy パターン
9.4 新たな要求の取り扱い，より

例 9.1 Java コード (抜粋)：Strategey パターンの実装

○ その前のクラス図 (図 9.4) とメソッド名が違う
  クラス図：SalesOrder#calcTax
  ソース  ：SalesOrder#process
  確かに違う


9.5 Strategy パターン
pp. 138
> 注：使用すべき特定の実装を選択する責任は Client オブジェクトにあり，
> その後，責務は Strategy パターンにおける Context オブジェクトに引き渡される．
○ どういう意味？
   例 9.1 で USTax を new してるところのこと
   本来はここで条件分岐する (実装の選択)
   リフレクションなどで動的にしたい
   実装を追加するたびに選択するところを変更するのはいや
   これって DI がよくやっていることですよね


pp. 138
9.6 フィールドノート: Strategy パターンの使用

○ 知らない制約が突然明らかにされる
  システム納入間際によくある
  法律の改正，日付や期間など
  システムの最下層への影響だけで済まず，表層まで波及することも

○ 方策の選択
  安直な選択をしてしまいがち
  結果は悲惨
  直さなきゃいけない，と思ったときはもう手遅れ (コストとか)
  技術的な判断ではなく経営的な判断をされてしまう

○ 納期と開発コスト
  Strategy パターンは納期とコストの両方を解決できるかもしれないパターンとして紹介されている
   pp. 124
  マネージャの責務は納期を守ること
  エンジニアの責務は保守に責任を持つこと？
  マネージャとエンジニアで立場が違うのが議論が噛み合わない原因
  箱 (クラス？) が増えると単純にコストが上がる (人月計算の世界)
  クラス数を抑える戦略を取りがち

○ 参考書籍
  プレファクタリング―リファクタリング軽減のための新設計 THEORY/IN/PRACTICE
http://www.amazon.co.jp/exec/obidos/ASIN/4873112729/503 8563742 3605535
  パターン指向リファクタリング入門~ ソフトウエア設計を改善する27の作法
http://www.amazon.co.jp/exec/obidos/ASIN/4822282384/503 8563742 3605535

○ システムのライフサイクル
  日本にはライフサイクル全体に責任を持つ役割の人がいない
  システムを運用する発注側がライフサイクルに責任を持つべき
   本来は保守コストまで考えて欲しい


pp. 143
第 10 章 Bridge パターン

○ 名詞，動詞によるオブジェクト抽出の弊害
  本当に階層は深くなる？
   具体的なオブジェクトから一般化によって抽象クラスの導出を繰り返すことになって階層が深くなるのでは？
   直観的に継承関係を作るのが問題
   継承だけでなく構造についても含意している
   過去ログにもあった (UML モデリングの本質)
>> 読書会(UMLモデリングの本質)第2回議事録 (http://www.javareading.com/bof/umlmodel2.html)
>> Q　P61の名詞抽出法以外の方法はあるのか？
>> A　名詞抽出法は、かなり古い手法だ。
>> A　CRCカードとかポストイットのKJ法などもある。
>> A　名詞抽出法だと、エンティティ（モデル）でなく、ビューばかり出てきてしまう。

○ 共通性/可変性分析
  マルチパラダイムデザイン (ピアソンエデュケーション)
http://www.amazon.co.jp/exec/obidos/ASIN/4894712989/503 8563742 3605535

○ 図 10.3 が出てきたときに危険を感じる人はセンスあると思う


pp. 168
○ 突然出てきたリファクタリングは何を指しているのか
  この章自体が，最初に考えたクラス構造の Bridge パターンによるリファクタリングになっている
  最初の方とインターフェース自体は変更してない
   それぞれを実装する立場の人には影響しない，はず
  リファクタリング―プログラムの体質改善テクニック
http://www.amazon.co.jp/exec/obidos/ASIN/4894712288/503 8563742 3605535

○ リファクタリングはどのタイミングで行うべきなのか
  改修の必要が発生したとき，何かを追加するための取りかかりとして行うもの
  現状の内部構造を改善して，変更を受け入れられるようにする


pp. 170
> 囲み記事：熟慮 VS 使用
○ なぜ熟慮という言葉を使うのか？
  deliberate (熟慮)
  consider よりさらに慎重？

○ Bridge パターンは本当に変更に強い？
  少なくともワーストケースを保証できる
  作る数が N * M から N + M に減る，圧倒的
   実際には，Shape がすごい増えそう，Drawing はそれほどでも


pp. 172
> GoF がこのパターンを「Bridge」(橋)と読んだのは何故だと思いますか？
  Bridge の本来の意味は，概念的に二つのものをつなげる，ということだから


第 11 章 Abstract Factory パターン
○ 図 11.8 (pp. 186) で ProductC を追加したときどうするのがよいか
  AbstractFactory にデフォルト実装をしておけば，変更しない派生ファクトリクラスはそのままで大丈夫
   AbstractFactory は抽象クラスにしておく必要がある
   interface だとまずい
  DI はこれらを隠蔽してくれる
   設定ファイルのミスは実際にロードされるまで分からない．システムのブート時にチェックして欲しい
   Seaser2 のどこかで設定ファイル使わなくてもよくなった
   Convention over Configuration
http://s2container.seasar.org/ja/DIContainer.html#CoC


第 IV 部 すべてをまとめる：パターンを使って考える
エキスパートはどのように設計するのか？

12.2 違いを付加していくことによる構築
# Alexander のアプローチの紹介

○ 活き活きとした場所？
  原著では唯一無二なものという考え方をしている
  置き換え可能なフレームワークなど，IT とは合致しないのでは

○ 設計の手続き
  機能追加が基本になってる
  新規も保守も同じプロセスのようになるはず？
   ちょっと分からない

○ pp. 200「原則」というものに着目する
  本書には原則に関する記述がない
  書籍を読まないと分からない
  たとえば
   「道路は直行していること」←これはパターン
   「小さな窓が付いていること」←これもパターン

○ Alexander のアプローチが適用できないプロジェクト
  あるの？あるとしたらどういうもの？

○ 全体に存在するパターンを洗い出す
  アーキテクチャのことだろうか
  問題にマッチする既存のパターンを探すことではないか
  パターンといっても粒度がばらばら
  アナリシスパターンなど，粒度の粗いパターンを意識しているのかと思った

○ 建築は目的や枠組みが明確
  ソフトウェアでは「実はこうだった」的なことがよく起こる
  いろんな会社のシステムを統合するような場合など
  新たにアーキテクチャを考えるようなクリエイティブなことはできない，という意味だと思った

○ 参考書籍
  The Timeless Way of Building
http://www.amazon.co.jp/exec/obidos/ASIN/0195024028/503 8563742 3605535
  時を越えた建設の道 (鹿島出版会)
   図書館にある


第 13 章
CAD/CAM の問題をパターンによって解決する

13.2 CAD/CAM 問題のおさらい
# 要求
#   CAD/CAM モデルを読み込みフィーチャーを抽出する
#   さまざまな種類の部品を扱えること
#   CAD/CAM システムのさまざまなバージョンを取り扱う

13.3.1 手順 1
# パターンを洗い出す
# フォースは何か，関心事は何か，など整理していく

13.3.2 手順 2a
# すべてのパターンの組み合わせを考えてみる
#   実際にはそんなに多くならない
# コンテキストを生み出す
#   環境や設定のこと
#   パターン自身が存在するコンテキストだけでなく，自身が生み出すコンテキストにも注意する
# パターンのメタな概念
#   どちらが他方のコンテキストを生み出すのか判断できるようになる

# コンテキストを考慮する時の規則
#   最大の関心事はオブジェクトがすでに存在している上での関連
#   オブジェクトは必要になればいつでも生成できる
#   実体化方法について気にしない
#   オブジェクトの生成方法を考える前に，システム中に保持する必要のあるものを考察する


次回は pp. 211 囲み記事の次より．