読書会(アジャイルソフトウェア開発の奥義)第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パターン
から
以上。


[ 戻る ]