読書会(アジャイルソフトウェア開発の奥義)第6回議事録
[ 戻る ]
2005年04月16日 土曜日 読書会
出席者: 岩室 奥 高橋(智) 高橋(徹) 村山 村上 吉村 遠藤 根本(記)
300ページから
19.5.3 時間給の従業員の給与
リスト19-41の1.5のmagic numberは何か?
18.1.1 (p248)の仕様を併読のこと 残業は、通常勤務の1.5倍と設定
→ テストコード中では即値OKとしたい。
→ ただし、給与計算はBCD(Binary Coded Decimal)にしたほうが良さそう。
JavaならBigDecimalか。
19.5.4 設計上の問題
リスト19-55
, itsEmpid(empid)
, itsName(name)
のようにカンマが先頭に来る書式はあるのか?
→まれだがある、この方が行コピーでパラメーターが増やしやすい、
SQL文など書くときに便利。
19.6 mainプログラム
OODBMSは使われているのか?
→製造業ではよく使うことがある PDM (Product Development Management)
System
ではOODBMSがよく使われる、部品ツリー構造などの非定型構造が多い為。
OODBMSは
現状ではDTOが永続化オブジェクトにできないのと同じで、
JDOならもっと抽象度の高いTJDOなどの実装方法がある。
query言語はOODBMSごとのバラツキがおおきい JDBC,ODBCのような標準がな
い。
cacheをダウンロードして研究してみましょう。
第20章 パッケージ設計の原則
20.1 パッケージを考慮した設計
20.2 まとまりの単位:パッケージ内部の凝集度に関する3つの原則
20.2.1 再利用リリース等価の原則
トラッキングシステムの状況はどうなっているか、
→mavenは自分が依存するライブラリーの最新版を自動ダウンロードしている。
→com.sun.*とかもimportすれば使えてしまうがsunはそれを意識しているのか?
これでは閉鎖性が維持できない。
20.2.2 全再利用の原則
例:java.util.ListIterator と java.util.Collectionsにとってのjava.util
のような関係を指す、 ただし java.utilはごった煮になってしまっている。
.netにはDLLのversion番号を管理する仕組みがあるがWindowsそのものは、
選択的loadは不可能、同一名のDLLを同じ場所に置けないから、Unix系の
"xxxx.so.
20.2.3 閉鎖性依存の原則
Javaはパッケージの移動はない、追加のみでの進化。
java.util.*の内容のごった煮感は解消不可能。
20.3 安定性:パッケージ同士の結合度に関する原則
20.3.1 非循環依存関係の原則
20.3.2 Weekly Build
20.3.3 依存サイクルを絶つ方法
誤記: p327 そのパッケージのテストを走らせければ → 走らせたければ
20.3.4 パッケージ依存関係グラフにおける循環が与える影響
delphiは循環参照を許さないが、Javaは循環可能のことがある、一つ前の
バージョンのjarがあれが可能になる。普通は相手のclassが見えないので
相互にコンパイル不可能。
このパターンに陥ると、ビルド不可能なモジュールができあがる。
20.3.5 循環を絶つ方法
aNewPackageにくくり出す、このパッケージはinterfaceのみのパッケージ
にしても良い。
20.4 トップダウン設計
つまり、パッケージはツリー構造を示す物ではないという趣旨。
20.5 安定依存の法則
誤記:p331 下から4行目 変更すること意識して作られたパッケージが→変更す
ることを意識し
20.5.3 パッケージ全てが安定している必要はない
20.6.1 抽象度の測定
20.6.2 主系列
純粋インターフェイスとは?
→C++の世界の表現で、Javaでは無視してよいだろう。
HRダイアグラムとは 恒星の明るさと温度のグラフのこと、(分かりにくい!)
この章は、結局パッケージ分割方法の基本ルールが不明のまま終わった。
第21章 Factoryパターン
Circle c = new Circle(origin, 1); がダメな理由がいまひとつ不完全。
半径が自由に定義できる円という意味では自由度がある。
→ DIコンテナはさらにFactoryさえも追放したものであると言える。
21.2 図21.3はAbstract Factoryに見えるが、なぜProxyパターンなのか不明。
21.3 テストにFactoryを使用する
第22章 給与システムのケーススタディ:ふたたび
22.2 閉鎖性共通の原則
以上.
[ 戻る ]