読書会(アジャイルソフトウェア開発の奥義)第9回議事録
[ 戻る ]
今回は、翻訳者の瀬谷さんが特別参加してくださったので、「特別版」
です。
PS.
[凡例]
「28.3 acyclic visitor pettern」
^^^^ 行頭から章番号から始まっているものは本の章のタイトル
「acyclic visitor は visitor の変形る」
^ 先行するものなにも無い場合は、本の内容や、メモ
「Q. ここでいう API って ?」
^^
「A. JDBC のことでは ? ( 見方によるが.. )」
^^ Q./A. で始まるのは主に、会話記録
「S. 依存関係逆転の法則を適用した点がポイント」
^^ S. で始まるのは、瀬谷さんからのコメント !!
# この表現に関しては、事前に、瀬谷さん
# の御承諾を頂いております。
## 御快諾、ありがとうございます >> 瀬谷さん
-- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< --
java 読書会
BOF in 高津区民館 第 4 会議室 at 2005/07/16 10:00 - 17:00
出席者(敬称略)
前
開始 →
+---------------+↓
| |
| 机 |
| |
+---------------+
↑ ←
金井, 小棚木, 中島, 高橋(徹)o, 門脇
村上, 岩室o, 村山
SEYA*, 高橋(智)o, 遠藤o, 吉本, 塩沢
栗野, 根本
朗読者: 高橋(徹), 岩室, 高橋(智), 遠藤
書記: 栗野
本 : 「アジャイルソフトウェア開発の奥義」
==
後、二回で終りたいので、p.500 位を目標に...
次回は、残業 ( - 21:00 ) Okey
次の本を選ばなければなりませんが、投票には、2 月位かかるので、侯補図書の推薦をお願いします。
# 参加者が多いのに、投票が少いのはなぜ..
Q. Java Puzzle は ?
A. 英語ですね.. 今なら、まだ在庫があるはずだから、手にはいりやすいかも
A. (英語なので)話者の担当者を予め决めるための CGI も作らないと..
Q. 英語訳の問題だけでなく、そもそも意味が解るかどうか.. (puzzle だから..)
==
# 今日は、訳者の SEYA さんがきている !!
[自己紹介]
<<削除>>
==
p.500
28.3 acyclic visitor pettern
# エイサイクリック
# 目標は 80 ページ
visit される側 ( modem 側 ) が、visitor ( Modem Visitor ) に依存している
逆に、visitor も visit される側に依存する。
=> 関係が循環 ( ciclic ) になっている。
visit される側 ( modem 側 ) が変更されない場合に利用できる
# visitor 側は継承しても Okey
純粋な visitor pattern では、 visit される側が visitor を知っている必要がある
結合が強くなっている。
visit 側に変更を加えると、visitor 側を compile し直す必要がある
C++ の場合は、逆も真なので、大変
この問題を解決するには..
acyclic visitor を利用する
acyclic visitor は visitor の変形
縮退クラスを利用して実装
# 縮退クラス : メソッドを持たない ( マーカーインターフェース )
# cf. p. 497
[誤殖] p.501 の脚注 「maker インターフェース」 => 「marker インターフェース」
acyclic visitor
# 180 回転して、派生クラスから I/F に切り換える
# キャストが成功すれば、正しいものが選ばれ、実行される
=> visit する側を変えても、visitor 側に影響しない
accept method
try - cache でかこみ、キャストしている
Q. List 28-16 は、p.499 の 28-7 と同じでは ?
A. Yes : (内部) Logic は変っても、Test Code は同じ..
これならば、循環する関係がなくなるので、順番に Compile できる
キャストを使っているのがよくない
パターンが複雑
組み込み系では、時間の制約でだめかも
S. 依存関係逆転の法則を適用した点がポイント
関係の間に抽象クラスを導入する
依存関係を断ち切ることができる
# 発想として自然
これ位ならば、単純かも..
だんだん、新しい物を入れて行くと複雑になるので..
Q. java のキャストって、関係がなくてもキャストしてよい ?
動的にやるから Okey ?
A. Yes, But, compile error ( fail first ) でないから嫌われる。
Q. マーカ I/F の必要性は ? (Object で十分では ?)
A. 確かに、この機能は Object でも Okey
A. 少しでも Compile Error にしたい
A. 普段は LWL を使っているので、必要性が、よく解らなかった..
Q. dynamic キャストは 400 倍遲い ( java )
A. クラスの継承をおっかけるので.. ?
Q. 比較している相手とは ?
up cast と比較して ( donw cast は.. ) ってこと ?
[宿題 ?] 本当に遲いの ?
# 255 段階の継承をさせて..
# JDK だと、Compiler ができないとか..
S. 時間がかかることも問題だが、どの位かかるかが解らないので、実行時間の予測ができない。どちらかと言えば、その方が問題 ( real time system では.. )
Q. Rela Time Java では.. ?
S. そうゆうキャストは許さないのでは ?
28.3.1 Acyclic Visitor パターンは踈行列に類似
Acyclic は、( Visitor と同様 ) 関数行列を作るが、踈行列になっている場合
# 要素が 0 の所は、実装がなくても良い所を表現している
=> 一つの利点 ( 特定の組み合わせを無視してよい )
28.3.2 レポートジェネレータで Visitor パターンを利用する
利用する場合
構造が複雑なデータ構造に、レポート機能を実現する場合
レポート機能を本体から分離できる !! (SRP)
# 後から、いくらでも追加できる
Q. PieceMap は何を表わしているの ?
A. System に含まれている個々の Piece (Parts) の個数を数えている
A. LWL でならば、1, 2 行で書けるものを長々と書いている.. ( 大変かも.. )
Q. BOM って ?
S. Bill of Materials といって、B/M の部品表など..
Q. Private Method に作られる Inner Class も Public Class となる
Security Hole になるかも ??
Coding 規約上では、Private Method での Innter Class は、ご法度
A. そうゆう場合は java はやめろ..
Q. 問題になるケースは ?
28.3.3 visitor pattern のその他の使い道
例:
Compiler の最適化
Setup ( 初期化 Routing )
visit される側は visitor から分離している点が利点
==
28.4 Decorator パターン
既存のクラス構造に手を加えずに、メソッドを追加する手段を提供
振舞いをパーソナライズしたい..
=> パーソナライズの部分を分離する
# そうしないと、週 80 時間の残業が必要に..
Q. 本当に残業は 80 時間で十分なの ?
A. 空しいからやめよう..
パーソナライズ部分の実装をプログラマに強制するには..
Template Method パターンを使う
# プログラマの記憶に頼るには危険なので..
CCP/SRP を適用しよう.. ( Modem は、User の希望を知らなくてもよいはず )
=> Decorator パターン
追加機能(User の希望)を本体から分離する
Q. Modem I/F に setVolume があるのはまだ、好ましくない形が続いている ?
A. setVolume そのものは、Modem の機能だから良いのでは ..
Q. 別に I/F (setVolume のない) を作るのでは ..
A. そこまで考えていないかも..
Q Dial で setVolume してはいけない ?
A. Yes # 結局、「どこでやるか」の問題
# 機能の集中する場所の違い
28.4.1 複数の Decorator
ModemDecrator 抽象クラスを作ると、Decorator が作りやすい
Q. 最後のパターンは C++ だったら、多重継承 ?
A. 多重継承は不要では ?
Q. delegate を使わないってことか ?
Q. 最後の例は Decorator になっている ?
==
一旦、昼休み
S. 翻訳は大変.. たった 1, 2 行に 1 時間以上かかることも..
妥協すると、クオリティが下るので...
Q. 全部を訳すのにどのくらい.. ?
A. 一年かかった..
本業は別にあるし..
S. 日本語にするには、大変 ( 流し読みなら簡単なんだけど.. )
Q. 「ぶつける」って ? ( cf. 以前の議事録 )
S. ダイヤモンド継承で、親でまた継承関係がぶつかる
Q. 原文があるとかえって難しい
なければ、自分の言葉が使える
「日本語」にするために、工夫が必要
# 追加をしている部分もある。
Q. 訳注を入れるのは ?
A. スタンスの違い
訳注を多用する翻訳者の基本スタンスは、「原文を読め」
二つのスタンスの違い
直訳 + 註釈
超訳 ( 日本語にするように努力.. )
==
28.5 Extension Object パターン
既存のクラス構造に、機能を追加するもう一つのパターン
# 複雑だが、パワフル
機能を名前で呼出す仕組 ( Q. Command パターンとの関係は ? )
Q. 「役割が違う２つのクラスを、『同じクラス階層構造』に押し込める」 ?
S. 『一つのクラス』の意味かなぁ
Q. これだけ読んでも、良く解らない.. (list 27 - )
# TestCase を積み上げることによって、作り上げた
Q. どうゆうふう考えれば.. 良いのか.. ?
A. Core の部分を先に調べたら ? ( Piece とか )
A. 今回だけ Test が先
[誤殖] List 28-36 クロオビのファイル名の所の exception は extension の間違い
S. (最新版は..) 直っています
A. 第1版なので..
[誤殖] p.526 本文 1 行目 「BOM 『オブジェク』に」=>「BOM 『オブジェクト』に」
S. これも直っています
28.6 結論
既存のクラスに影響させずに、機能を追加できるパターン
OCP/CCP/SRP/LSP/DIP
Q. 「9 章」って..
A. 色々な図形を扱う場合
S. (9 章では、まだ、必要なパターンが説明されなかったので..) 新しい図形を作る度に、クラスへの改変が必要だった、
visitor パターンは「既存のクラスの階層構造に変更を加えずに、機能を追加する」ので、これを利用することによって解決(クラスの改変が不要に)できるはず。
S. この 28 章の三つのパターンの共通な性質は
「既存のクラス階層構造に手を入れずに、機能を追加する」
こと。
Q. 御利益が理解りにくい
S. 既存のクラス構造が変っていない
S. visitor パターンだと SRP 違反なので p.519 図 28-7 の Extension Object パターンが利用される
Q. 図 28-7 ってエッセンス ?
必須メソッドがみえない ( パターンを作るのに.. )
S. インターフェースに依存するので、そちらで、必須メソッドを定義することになる
(インターフェースは..)やりたいことを記述する部分なので自由にしておよい
Q. 部品のことしか考えなくてもよいクラスが作れる
extension の方は、やりたいことは(パターンとは)別々なので..
S. 図 28-7 は、SRP を実現している
S. 本当にここまでやる必要はないかも..
Q. よいことかもしれないけど、土台が大変
S. visitor は使える
組み込み系で、テストケースを作るのに、対象に触らずに、(テストケースが)実装できた。
S. 「既存の物に手を加えずに、なんとかしろ」の場合に便利
Q. exntesion は、文字列を渡して、メソッドオブジェクトを取ってきている
リフレクションに近付いている
Q. オブジェクト指向と関係ある ?
Q. Aspect との比較は ?
# (Aspect に関連する..) JSR の内容がまだ、中身がない
A. 目的は一緒かも
Q. Aspect で class 継承もあるってこと ?
Q. コンパイル 時 ?
A. 実行時もある
実装により違う
Source/class/Byte Code
Aspct/J は、Class の変更
Seaser は Class Load 時
A. Aspect の利用例の資料がある
cf. AOP@Work: AOP Tools comparison, Part
( IBM developerWorks )
パターンを Aspec で実装するという話
==
29. State パターン
Q. 「変更の手段もなければ、保存の手段もない」って .. ?
S. 変更する必要がない場合は、保存してもしょうがない ?
Q. 引用の場合(の翻訳)は ?
S. 基本は自分で訳すが..
S. 詩などは、過去のを探して、それを使う (原則)
あんまり意味がわからないと結局、訳す
Q. この一行でとっても時間がかかっているのですね..
S. Yes
29.1 有限状態オートマトンの概要
Q. 「丸の部分」の「丸」って..
A. 「楕円」の部分でしょう ?
Q. 英語では ?
S. Circle でした
Q. 表って ?
S. 現在の状態とイベントによって、次の状態が決る
Q. マイナー状態
S. 設計者が見落しそうな状態のこと
S. プログラマは、正しく動く場合しか考えない
A. if 文のカスケードで条件を書くと、稀な場合を見逃すとか ..
遷移図を書くと真剣に考えるかも
状態遷移図では、もれがなくなる !!
S. これ(図 29-2 の誤り)は、最初に笑えないと思った。
S. 何度、お金を入れて Thnak you というだけ
Q. あっていけないこと ?
A. それは、設計の問題なので..
A. 追及してもしょうがない ( cf. Hollo World )
Q. 「(笑)」は、「:-)」だったの ?
S. 本当に文字で ( "smile" と ? ) 書いてあった。
Q. 初期状態って ?
S. Locked から始めている
Q. ◎から始めるのが正しいのでは .. ?
S. Yes
(この著者の)方針として、状態遷移の話の説明に関しては、(その機能が)必要になった時点で、必要な記法を導入する形 ( 正確な説明は p.629 付録 B )
29.2 有限状態マシンの実装テクニック
29.2.1 入れ子の switch/case 文を使った実装
List 29.1
Q. (この switch/case 文の実装は..) 第一感、うざい
A. 最初だからまあ、しょうがない..
Q. 何故、(インスタンス変数 state が..) private でない ?
S. この後に記述
遷移毎にテスト関数がある
State 変数が private だと Test から、アクセスできない
# Object 指向のドグマの一つ「calss instance は private にする」
Q. instance 変数は全て private ?
A. protect は許されるのでは ?
Q. なぜ getter/setter はだめ
A. Test のためだけに使うメソッドを実現する意味がない ?
A. 賛否両論
(テストの時にだけ利用する場合とそうでない場合を) 区別する仕組が欲しい
アノテーションが使えるかも
Q. java に friend があれば..
A. java 1.7 が入るのかも..
Compiler レベル
VM レベル
の変更
A. 無名クラスって、ほぼ firend だよね.. ?
Q. 状態遷移を持つプログラムはデバッグが大変
A. assertion を使うのかなぁ..
[switch/case の問題]
状態が複雑になると、大変
状態と実行部分の分離ができていない
Q. これ(p.535 の下から 3 行目から、そのページの最後まで..) ってほんと ?
S. かれらはコンサルをやっているので、その経験(コンサルを担当した会社で作られていた多くのコードを観た)を述べている
29.2.2 遷移テーブルを使った実装
Q. このような書き方(List 29-4 の 「unlock()」)はできるの ?
A. C++ ならできるけど java ではできない ?
「unlock オブジェクトを返すメトッド」という仕組
S. p.549 の上の方を参照
A. 関数へのポインタやメソッドへのポンタがないから..
下手に java を知っていると混乱する
# switch/case より table の方が簡単
[table の利点]
記述が容易で、
table の内容を実行時に変更可能
複数の Table をもてる。
[table の欠点]
効率
table の検索
Q. Hash を使えば、もっと速いはず
A. 多重配列にすれば早くなる ( 実装の問題 )
table 操作のための細々したコードが増える
==
[休憩]
A. (state pattern を..) 初めて使った時には、目から鱗
S. 状態が抜けると大変なので、組み込みではよく使う。
A. MS の tool は「1G の限界」があるらしい..
それ以上のデータを扱うと止る..
==
29.3 State パターン
Q. 点線が途中から実線になったが .. ?
S. 点線が二つ重なったので.. ( たまたま実線のように見える.. )
どうしようか悩んだが、「原書通り」ってことで..
## Q. State パターンと継承の関係は ?
Q. Interface に public が抜けている ?
S. ( State パターンは ) Method だけなので Instance が不要
# Strategy との比較
コンテキストを上位で保持し、状況は派生クラスで担う
S. State パターンは、実は、Strategy パターン
Q. Strategy は生成パターン / State は動作パターン という違いがあるのでは ?
Q. 区別の仕方は色々あるから..
S. テンプレートでも Strategy でも同じことができる
Strategy はテンプレートよりクラスが多いので柔軟性が高い
この二つの目的は、共に、継承クラスの再利用を目的とする。
S. 同じ図式 (UML) は同じような性質を持つ
意味的な区別ではなく形式的な区別
# Cost と Merit
=> State (論理) と Action (動作) が分割できる
効率がよい。
table の柔軟性と、switch/case の効率
[Cost]
table を作成することが大変
論理が複数の state に分散してしまう
A. State の数だけ Class ができてしまう
A. State が 150 位のシステムは作った経験がある ( もちろん生成 tool も作った )
# 空港の制御なので、許可がでないと次の state にならない
Q. 仕様は ?
A. 図 ( visio ) で..
Q. ありえないケースがあれば状態は減る
Q. 漏れが出たら ?
A. 表だから、漏れが出にくい
A. コロコロ仕様が変ったら困る
状態遷移コンパイラが欲しい
29.3.1 状態マシンコンパイラ (SMC)
状態遷移 table の実装を効率化
S. コンパイラを走らせると、状態遷移パターンのパーツが作られる
生成されたコードは ( binary と同じくらい.. ) 触らなくてもよい
S. これを使うときに入力されるものと生成されたものが List up されている。
SMC は、他の全てのパターンの利点を全て得ている
デメリットは tool の使い方を学ぶこと..
S. 本気で使うつもりなら便利
Q. state が少ければ.. 使わない
量が多ければ使いたくなる。
S. ( Table 作成は..)手動だと退屈
Q. プロジェクト毎に似たようなツールが.. ?
使える時には便利だが、使わないと全然..
Q. (Tool の)カスタマイズが必要 ?
Q. Compiler Compiler のように使える状況が結構ありそう..
29.4 状態マシンはどのようなところで利用されるのか ?
29.4.1 GUI の上位レベルのアプリケーション方針
UI の目標は状態をもたせないこと
=> ユーザは状態を把握できないから、UI で状態をもってはいけない
=> 状態を持たない Code は状態に依存する ( 状態により、振舞いを変えなければならないから.. )
Q. 「(p.544 下から 3 行目) 状態コンパイラを使ってる」って ? SMC のこと ?
S. menter (http://www.objectmentor.com/home) には C 版 (前任者) もあるので、これのことかも
Q. 「前任者を作ったエンジンを使っている」とも、読めるが..
S. そう読めるかも ( Matrix のイメージがあって.. )
Q. (List 29-11 は..) どのカラムがどの意味をもつか良く解らない
A. state, event, action
A. 引数に、名前と値に対を与える言語があるけど、そちらの方が理解りやすい
# 上位レベルの方針が一箇所に入っている。
29.4.2 GUI との対話コントローラ
User との対話状態と表示も、状態遷移で表現できる。
Q. 図 29-6 の event が解らない
A. Quit なので、WaitForDown では ?
A. Canvas の状態が記述されている。
user からの event 入力で状態が変っている。
29.4.3 分散処理
Protocol の実装にも State が使える
29.5 結論
29.6 List
# 手動で書いたものやジェネレータで書かれたものが載っている
# ジェネレータ用のテストコードは、他のテストコードとほぼ同じ
Q. (list 29-16) 拡張子に SMC が付くのが気持ちが悪い
A. 自動生成する Class 名では ? 前のはファイル名でなくパッケージ名
Q. パッケージ名が SMC でよい ?
A. まだ rule 前だから ? ( 大文字だったり.. )
A. JDK 1.1 対応 :-)
Q. 自動生成されたファイルを配るとすると、この package 名は辛い..
Q. jar にいれる場合、manifest に情報を入れて欲しいかも..
Q. (より一般的に..) freeware を使うのはよいけど実行可能 jar を作るのが大変
A. (利用する jar を class ファイルに..) 一回展開して、もう一度、まとめる
実行するだけならこれだが、version up が大変
Q. package 管理の機能がもっと欲しいよね..
A. どの version を使っているとかの Document も欲しい
29.7 参考文献
Q. 推薦図書と同じじゃない ?
A. java じゃなかったような ? 改訂版 ?
==
30 章 ETS のフレームワーク
# 再利用可能なフレームワークの設計経験
[誤殖] 「下図」を減らすには => 「数」を減らすには
S. (ワープロ変換ミス)第三版では直します。
A. これでも意味がとおりそうなのが楽しい
[誤殖] (p.560 の 30.1.2 のタイトル) 「1933 年〜」 => 「1993 年〜」
S. 直っていない
[誤殖] (P.560 page の真中当り) EST => ETS
30.1.3 フレームワーク
Q. ETS のエンジニアも作り始めた
S. ETS のエンジニアが OMI のフレームワークで作ろとしたら駄目
部分的に作る
Q. 最初の 5 問は、ETS の人が作り、フレームワークも作った
# 失敗の要因 : 他の問題を無視していた
# フレームワークそのものが難しい
Q. 難しいというのは簡単だが..
A. 汎用な物は、(分析等を行って.) 作る必要があるから..
Q. copy & past ? ( emacs な人は cut & past )
Q. プレッシャーがあると、ついつい、フレームワークに手を入れてしまう
Q. OO 方法論は「フレームワークありき」で始まっているが、そのフレームワークはどうやって作るの ?
A. (一般的な良い ?) 方法はなさそう..
フレームワークの上には(問題領域)アプリケーションがあるので、それを扱わないと..
フレームワークのフレームワークはだめ ?
S. フレームワークを作るには、問題領域の深く広い経験を持つ必要がある。
Q. 現場を知らない駄目 ?
A. それより重要な点がある
Q. フレームワークの問題領域って ?
A. サンフラシスコ フレームワークは.. ?
アメリカでは、電力会社では成功した (買収が多いでの共通項目が多い.. )
日本では、独自仕様があるのでだめ。
Q. そもそも何のフレームワーク ?
# 6 万行のフレームワークは捨てた
フレームワークを先に完成させるのはだめ
実際に動く(フレームで動く)ものを作りながらフレームワークのコードを作る
# 最低、三つのアプリケーション
32.2.4 結論
# 古い版は、すべて捨てることになった。
Q. フレームワークは二回作った ? ( 違いは ? )
A. 二回目は、他の場合も想定して作った
# 最初の部分は、せまい Domain しか考えていなかったから..
対象として、バリエーションのあるものを選ぶ
A. アプリケーションと、フレームワークを同時に作った
==
Q. (図 30-1 は.. ) なんの絵かよくわからないが... 色々な分野があるってこと ?
S. A とか U は理解りにくいかもしれませんが、前のページに定義がある..
Q. 表が虫食いなのは ?
S. その組み合わせはありえないので..
S. ちゃんとおっかけると、意味が解るはず
最初に自分で読んでも解らなかったので、原作者に例を増やしてもらい、その結果を反映してある。
Matrix を変更することによって、(重み付けが代わり..) どのような心理分析したいかを選択できる。
非常にたくみな仕組 (この仕組そのものを考えることが難しい)
Q. Test(試験結果の分析) のプロがいる ? ( プログラマの発想じゃないよね.. )
S. YES. ETS にいるプロによるもの
S. 「vignet」は「小問」と訳した
A. vignet (ビニエット:フランス語から)
S. 基本的には、点線の先のクラスを作成するだけで、後はフレームワークでやってくれる
他に、Matrix も必要だが、これを作るためのツールもあり、それは、用意されている Dictional から、拾ってきて、作りましょうという話。
Q. この話は一旦ここで、終るの ?
S. もう少し続くんだけど、微妙..
==
次回は 08/27 (LWL とぶつかるかも !! )
-- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< --
[ 戻る ]