読書会(デザインパターンとともに学ぶオブジェクト指向のこころ)第6回議事録
[ 戻る ]
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
2006/06/10
「デザインパターンとともに学ぶオブジェクト指向のこころ」第 6 回議事録
時間：10:00 - 16:30
場所：てくのかわさき 第５研修室
参加者 (敬称略)
高橋(徹)，高橋(智)，遠藤，村山，岡澤，小棚木，中島，和田，早川
読み手 (敬称略)
根本，岩室，吉本
書記
小松
p307 第 21 章 Singleton パターンと Double-Checked Locking パターン
よりスタート
■p310 例 21.2 Java のコード（抜粋）
○CalcTax と USTax の両方で getInstance メソッドが定義されている
⇒CalcTax を見せて各国の Tax は隠蔽したい
⇒最終的には AbstractFactory のような形になる
■p311 Singleton パターン：鍵となる特徴
○インスタンス取得メソッドの名前は getInstance にするのが決まり？
⇒get〜のような名前を好まない人もいる
⇒標準APIでも統一はされていない
○getInstance という名前だけでは Singleton かどうかがわからない
⇒Singleton かどうかはドキュメントに記載されるべき
○複数インスタンスを持つ Singleton はあり？ 3gleton とか 4gleton とか
⇒GoFの定義では、基本はひとつ、但し増やしてもよい
⇒インスタンス数を制限するパターンであり、ひとつに制限する訳ではない
⇒複数でもよいとすると ObjectPool との違いは？
⇒回収があるかないか
○ThreadLocalSingleton や Contexton も欲しい
○図21.1 の UML にコンストラクタがないのは記載漏れ？
⇒その他表記もあいまい そもそも標準に則した UMLツールはあるか？
⇒どのツールも独自実装が多く、これでは標準の意味がない
■p312〜 21.4 兄弟分：Double-Checked Locking パターン
○いつ、誰が考えた？
⇒C++ の時代からある
⇒優秀なスレッドプログラマが書けば誰でもこういう形の実装になったのでは
⇒名前はないと不便なので後からついたのでは
○パターンというよりイディオム？
⇒イディオム本もあればよいのに
⇒パターンに比べてイディオムの旬は短いのかも
⇒do-while は不滅（笑）
○volatile による最適化の回避は Tiger であれば可能？
⇒可能なような気がするが調べてみないとわからない
⇒以下の記事が参考になる
http://www-06.ibm.com/jp/developerworks/java/040514/j_j-jtp03304.html
○Double-Checked Locking の問題はどのように再現すればよいか？
⇒『Java Concurrency in Practice』にサンプルコードがある？
○例21.4 の解決策は最近よく見られる
⇒Instance を内部クラスにしているのはなぜ？
⇒Instance への最初のアクセスまで生成を遅延するため
■その他
○Singleton を途中から導入する、あるいは途中から Singleton でなくするのは可？
⇒後者は難しい
⇒Singleton は一歩間違えると Global 変数になってしまう
⇒初心者に与えると危険
第 22 章 Object Pool パターン
■p318 図 22.1 個人向け投資システムの 3 階層アーキテクチャ
○実際にはクライアントのブラウザを含めた 4 階層ではないか？
■p327 Grand, Mark. Patterns in Java - Volume 1, A Catalog of Reusable
Design
Patterns Illustrated with UML, New York: John Wiley & Sons, Inc.,
1998
○邦訳があるはず
⇒『UMLを使ったJavaデザインパターン―再利用可能なプログラミング設計集』
http://www.amazon.co.jp/gp/product/4877830138/250-8695630-4944247?v=glance&n=465392
■p327 図 22.2 Object Pool パターンの一般的構造
○Java では最近は Object Pool を自前で作ることは少ない
⇒Hibernate には C3PO というコネクションプールの実装がある
⇒特別なカスタマイズが必要なら自作もあり
⇒Object Pool を使用せず GC 任せにしてもよい
○オブジェクトが規定回数取得されると自動的に解放する機構も必要
■p328 22.6.3 あなたの意見
> ... 書かれていたことがいつ役に立つのかは判らないのです。...
⇒Fragile Base Class Problem
⇒親クラスへの変更が子クラスに及んでしまう問題
⇒継承の乱用の問題が大きく取りあげられる以前から提唱されていた
第 23 章 Template Method パターン
■p331 23.4 Factory Method パターンとオブジェクト指向言語
> C# におけるコレクションは、IEnumerable インタフェースを実装しています。
⇒インタフェースの頭に "I" を付けるのは賛否がわかれる
⇒C# などでは extends と implements の区別がないのである方がわかりやすい
⇒命名は議論が尽きない
> C++ では、begin()、end()、等でファクトリメソッドが使用されています。
⇒実装によるので何とも言えない
（この辺りの話の繋がりを失念）
⇒Mustang では Escape analysis によりスタックアロケーションが可能になる
⇒そもそも C++ で malloc する方が遅いのに Java は遅いとみなされがち
⇒C++ でも MemoryManager で効率化を図っている
⇒以下の記事が参考になる
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml
第 24 章 ファクトリのサマリ
■p335〜 24.2 ソフトウェア開発プロセスの手順
> 新規コードを開発するコストよりも、既存コードを変更するコストの方が圧倒的に
> 割高なのです
⇒この事実は本当に認識されているのか？
⇒プログラマの多くは認識しているが、マネージャで認識している人は少ない
⇒認識していないマネージャを説得すにはどうすればよいか？
⇒数字で示すしかない
⇒メトリクスの数値と実際にかかった工数の実績をとっておく
○2段階の手順を踏んだアプローチとは？
⇒(1)インタフェースと実装を分離し、(2)新規機能を追加する
⇒最初から拡張ポイントを用意しておけばコストが抑えられる
■p337 24.4 システム規模に見合ったアプローチ
> システム中に A と B という 2つの実体がある場合、その関係は A が B を使用する、
> あるいは、A が B を生成／管理するのいずれかのみに留め、決して双方の関係を同時
> に成立させてはならないのです！
⇒循環させないということ？
⇒生成する側と使用する側を分けるということ
⇒new したら call するな call したら new するな
⇒生成／管理とひとくくりにしてしまうのは危険な香りがする
第 25 章 デザインパターンのおさらい：総括と今後
■p348 25.11.3 あなたの意見
> ...あなたが得た、最も興味深い、あるいは最も有効な洞察を答えてください。
⇒分析マトリクス
⇒第IV部（第 12, 13 章）のコンテキストに関する話
第 26 章 参考文献
以上
次回からは新規課題図書 今日（ 6/10 ）から投票開始
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
[ 戻る ]