読書会(アジャイルソフトウェア開発の奥義)第4回議事録

2005年02月19日土曜日　読書会議事録　

　出席者:(敬称略) 高橋(智) 高橋(徹) 遠藤　岩室　奥　久保　金井　原井　門脇　
村山　吉村
　　　　　丸山　吉本　小棚木　　根本(記)
　
第11章　P163  依存正逆転の原則(DIP)
11.1 依存正逆転の法則から
　■上位と下位の定義が不明　WhatとHowの関係とみていいのか?　レイヤー設計のこ
とか?
　■依存とは何か? それがないとコンパイルできないという定義で良さそうだ。
　　クラスライブラリの考えで、良さそう。
　■Martin Fowlerの言うPOJOは、flamework非依存での話。
　■DIとは依存性をinterfaceのみに手中させる考え方らしい。
　■POJO(Plain Old Java Object) POJI(...Interface) もある、
　■POCO (Plain Old C++ Object) という言葉は、ローカルな話。
　■C++は標準のObject classがないので、フレームワーク依存度が高い。
　■DIは外部への依存は、自分が書くのではなく、Frameworkが渡してくれると思っ
て使う手法、
　　intefaceにのみ問い合わせて、実装クラスに対しては問い合わせない。
　■interfaceの互換性問題の解決が不明。
　　例えば、S2Containterの定義するinterfaceはアプリには入らない。
　　getComponent()のようなコンテナ依存APIは、アプリ側は使わないのが流儀。
　■インターフェイス依存のコーディングか今後主流になるかもしれない。
　　S2** がたくさんあって、調査が必要。
　■SmallTalk Objective-Cの様に相手の型に依存しない書き方にしていきたい。
　■コンテナに問題があった場合、どうするのか?
　　コンテナが問題を起こす可能性は高まるが、アプリプログラマーが書くよりは、
まだマシなはず。
　　コンテナ開発者にがんばってもらいましょう。

11.2階層化
　■図11-1はTemplae Methodを否定している物ではないらしい。
　　リスコフの条件を"多段式Template Methodパターン"(バグパターン)は満たさな
いのでダメだろう。
　■図11-2は使う側が自分の好きなinterfaceを公開して、実装者に埋めてもらう構
造となっており、
　　逆転している。これこそが「リーン開発」! 必要なときに開発を要求する。
　■不揮発性とは? (多分 Non-volatile)か。
　■WSDLのまずい点は、interfaceまたはclassを書いてから定義するので、順番が逆
になっている。
　　WSDLは手書きできないので作りにくい。
　　CORBAは Corba-interfaceのみでの依存関係なので、実装としては正しい。
11.3 簡単な例
　■図11-4 <> クラス　と Lamp クラスの間で
　　　矢印が、　継承関係となっているが　点線であるべき
　　　△　     　／\　
　    |            |
　    |     　
　    |            |
　    |
　    |            |
　
　■p170  脚注  Pyrhon --> Python
11.4 暖炉の例
　■11-2図　が8086系CPUのportコントロールのCのコードで、歴史的背景を理解しな
いと理解しにくい。
　■Templateは動的入れ替えができない、マクロによる静的Factoryのようなものと
言っていいだろう。

11.5 結論

第12章
　■インターフェイス分離の法則 The Interface segregation Principle
  ■図12-1 Doorクラスは抽象クラスなのでイタリックでは?

12.2 クライエントの分離=インターフェイスの分離
12.3 インターフェイスの分離の原則
12.4 クラスインターフェイス対オブジェクトインターフェイス
12.5 ATMユーザーインターフェイスの例
　■図12-6
　　 Deposit UI は methodを一つしか持っていないが、要るのか?
　　  -> 他のUIとの並列配置による見やすさという意味がある。
　　 Closureという関数pointerを持った発想方法に見える。
　　使う物だけtypedefで引っ張ってくればよいのではないのか。
　　 "message passing"を"method call"にするか"event"にするかの区別に見える。
12.5.1 単一形式　対　複数形式
　■if (NewService* ns = dyamic_cast(s))
　　はjavaならinstanceOf()のイメージとなる。
　　　graphics と　graphics2Dのキャストのイメージと同じ、後から拡張された機
能の使い方の例。
　■Javaの@deprecated　で @no replacementという可能性はありえるのか、多分な
いと思う。
　■新しいVMは古いjarは常に読めるはず。
　■C#もdreprecardのmethodは出てきているかもしれない。
　　C# の1.0 1.1 2.0で変わった物はあるのかもしれない。
　　.NET Frameworkは1.0と1.1とで動くのか? なんとか動くと思う。

第3章　給与システムのケーススタディー
13. CommandパターンとActive Objectパターン
13.2 トランザクション
13.3 Undo
　■Memento Pattern のようだが、Mementoではない、つまり保存しているのではな
く
　  Commandオブジェクト自体がスタックされていっている。
13.4 Active Objectパターン
　■結局は自分でMultithreadを組み込むケースの話。
　  J2ME環境でMultiThreadを使いたい時に、自分で作り込む話らしい。
　■こんな、co-operative multithreadは自分では作るべきではないのではないの
か、
　　ちゃんと動く保証がない。

第14章 Template MethodパターンとStrategyパターン
　■結論: Template Methodは使い道がほとんどない。
　■JUnitの setUp() tearDown()は Template Methodのめずらしい好例かもしれな
い。
　■Bubblesort を実際に使うことあるのか? quickSortよりも最悪ケースではbubble
も遅くはない。

　■Hashtableが一番遅いという噂が出回っているが、誤解だ。
　　hashtableはjavaも昔は最初の16byteで作ったが、今は直っていて、同じHashが
固まりででてくることはない。
14.2 Stategyパターン
14.2.1 再びソーティングの話
　■Template Methodは常に DIP(依存性逆転の法則)に違反するらしい。
　　
第15章 FacadeパターンとMediatorパターン
15.1 Facade
15.2 Mediator
　■Windows APIも成功は1　だったが最近は 0以外となった。従って(found ==
false) の様な書き方がよい。
　■Javaなら isFound() を使う局面だろう。
　　
次回　第16章 SingletonパターンとMonostateパターン
から
以上。

[ 戻る ]