読書会(デザインパターンとともに学ぶオブジェクト指向のこころ)第4回議事録
[ 戻る ]
2006年04月08日
「オブジェクト指向のこころ」
出席者
高橋{徹} 中島 岩室 小棚木 大崎 村山 門脇 根本 岡澤 吉本
遠藤 石黒 小松 早川 和田
*P211 囲み記事より
**13.3.2
･複数のパターンを組み合わせるとき→パターン間に主従が発生する。
･組み合わさったパターン全体→コンテキストとはこのことか？
-----
･パターンの適用
→パターンがわからない人にはその有用性がわからないのでは？（cf.cobolerな上司など）
→SE,PGじゃないとわからないはず。
→･そのとき、PMはパターンの有用性を理解できるのか？
･理解してもらえない場合、そのSE,PGはパターンを使うのはリスクが高いのでは？
･SWPBOKによるとコーディングの工程は design & constraction
→･日本語訳としては、”構築”ぐらいのはずで、”製造”ではない。
（”製造”では、決まった部品の組立のような作業のような印象を受けるが、
ソフトウェア開発はそのような作業ではない）
･ソフトウェアファクトリーという言葉はおかしい。
･”ソースコード”の日本語訳の提案→”設計図”
･バイナリレベルでコンポーネント指向であるべき
→ライブラリで分かれていないと、毎回全体コンパイルするとに時間がかかる（c++など）
･”設計書”と”ソースコード”と”コメント”は重複があって、無駄が多い。
･Royceのウォーターフォールモデルでは、もともと反復が提唱されていた。
→ペンタゴンで行ったときに、例外的に反復せずに行ったのが広まったらしい。
･構成管理、テスト環境・本番環境などの構築、リリース手順などが考慮されないプロジェクトが多い。
･上流工程に携わる人々が素人集団であることが諸悪の根源
→マクドナルドのバイトの方が、10000倍いい。
･アジャイルという言葉を使うと上司が理解できないので合意されない。
→トヨタ方式、リーン式、見える化、カイゼンなどと言えばいい。
-----
**13.3.5 p216 L3
･”V1Facadeには、V1Impに対する指示を行うための、簡素化されたメソッドが保持されます。”とは？
→V1Impのメソッドの実装はがV1Facadeにあるということ
→V1Facadeのメソッドのなかで、V1Moduleを呼んでいる。
-----
･品質に対して、お金が出るような社会の状態になるのが理想。
→人月に換わる測り方がほしいが、その品質の測り方が難しい。測る人の恣意が入る可能性がある。
*宿題：結合度と凝集度をどうやって図るか調べる(eclipseなどのツールや、対角線の表などで)
**13.4
･コンテキストとは？
→p207 L14
→日本語で適切な訳がない気がする。一般に使われる”文脈”ではしっくりこない。
→”場”とか”空気”に近いのでは？
･フォースもわかり辛い。
→フォースの中にまた、”制約”がという理解で正しいのか？
第V部 新たな設計パラダイムに向けて
*第14章 デザインパターンの原則と戦略
**14.3
･誤記 下から4行目 ”図10.13”→”図10．15”なのでは？
･p255 L10 ”依存することになる”とは？
*宿題：p227 リストの中で、DIコンテナはどれになる？
･フレームワークはアプリケーションに依存してはいけない。アプリケーションにフレームワークが依存しろ？
→ハリウッドプリンシパルの逆？
･この節は、マルチパラダイムデザイン的な発想
･p229 最年長とは？
→ほぼ、オブジェクトの生存期間の意味では？
→SOAなどのようにインタフェースが要求されるものであれば、Facadeが最年長になる。
**14.5
･小さなインターフェース（1,2メソッドしか持たないインターフェース）
→ピーター・コード、ヤコブソンなど
**14.6
･p232 のリスト
→”パターン”という言葉を”Java”などの言葉に置き換えるとなんにでも通用しそう。
→落とし穴に、”覚えたからつかってみたい”というのも追加したい。
･パターンの組合せのパターンがあっていいのでは？
→それがフレームワークでは？
→パターンの組合せを30個ぐらい単純につくるのもよいかも。
-----
･stratege,template method VS yagni
→弾丸に撃たれてからやる。（だからyagni？）
*第15章 共通性/可変性分析
**15.3
･一つの事象を複数の観点で見る。
→マルチパラダイムデザイン
･hotpoint と coldpointを切り分け→パターンの当てはめ
というのが分析の常套手段では？
･共通性分析：普段分析のときは無意識にこうしているのでは？
→要求側は、単機能だけ考えて、共通性などを意識していないこともおおい。
-----
･p55の図4.3とp240の図15.6の設計では、後者の方が優れているけど、
実装では、前者の方が大変そうなので、大変なのに良くやったと評価されそう。
*第16章 分析マトリクス
**16.2
･行と列とは？
→単純に表16.3などの横軸と縦軸のこと
**16.4
･図16.3と表16.13の”住所の確認”は、”郵便規則”などの間違いでは？
･表（マトリクス）にすることは重要
→･お客さんが、その問題領域を把握していないときが多いのでは？
･マトリクスで洗い出すと、規模がでかくなる。→再見積できる契約にすることが重要
･”ヒアリング”ではなく”インタビュー”をする。
→･お客さんに主体的に情報を出すことを求めるのは無理がある。
･こちらのいい仕様に進められる。
･”現行と同じ”という言葉は使わせない。
･このマトリクスからコードを生成できないか？
→MDAとか、マイクロソフトのワークフローエンジンとか、togetherとか。
･軸が二次元ではすまないのでは？
→ex.会員と非会員で送料が異なるときなど。三次元、四次元がいるのでは？
→一覧に整理できることがメリットなのでは？だから、行追加や、列追加で、
対応したほうが良いのでは？
→図16.3のように、マトリクス内のマトリクスを使わない方がよいのでは？
･このマトリクスは、仕様書というより、コミュニケーションツールととらえた方がいいのでは？
次回は
p257 第VI部 パターンの持つその他の価値
より
以上
[ 戻る ]