[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 11863] Re: 16 日議事録

こんばんは。
吉本です。

土曜はお疲れ様でした。

今回は読書会に参加するようになって
不覚にも初めての不参加となってしまいました。
それでなくても人数が少ないズームインに行けなかったのが
非常に心苦しいです。(^^;)

先週の月曜にとあるデスマーチプロジェクトにヘルプで緊急投入され
解放されたのが日曜・・つまり昨日の朝方でした。
土曜は24時間会社に缶詰で・・とても。
今やってるアジャイルもぶっ飛ぶ一週間で残業60時間です・・・。

これで次回のネタはばっちりなのですが
個人情報保護法下では、ほとんどオフレコ状態・・。
興味がある人は飲み会ででもこっそり聞いて下さい。(^^;)

ということで前置きはさておき、
議事録から察すると、今回進んだところは
358ページの２２．２の終わりまでということでよろしいですか？
次回のためにとりあえず自分で読んどこうかなと思ってますので。


----- Original Message -----
送信者 : "nemo_kaz" <nemo_kaz@xxxxxxxxxxx>
宛先 : <jfriends-ml@xxxxxxxxxxxxxxxx>
送信日時 : 2005年4月17日 9:38
件名 : [jfriends-ml 11860] 16 日議事録


> みなさま、昨日はお疲れ様でした。
> 議事録をアップします。
> 根本
>
> -------------------------------------------------------------
> 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.<version>"のような命名の仕組みはWindowsにはない。
> 　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 閉鎖性共通の原則
>
> 以上.
>
>