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

[ 戻る ]


「アジャイルソフトウェア開発の奥義」 : 第八回議事録 (案)

をお送り致します。

PS.
[凡例]

    「26.2 天国への階段)」
     ^^^^ 行頭から章番号から始まっているものは本の章のタイトル

    「proxy が二つの差を吸収する」
     ^ 先行するものなにも無い場合は、本の内容や、メモ

    「Q. ここでいう API って ?」
     ^^
    「A. JDBC のことでは ? ( 見方によるが.. )」
     ^^  Q./A. で始まるのは主に、会話記録

-- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< --
java 読書会 

BOF in 高津区民館 第 4 会議室 at 2005/06/18 10:00 - 17:00

出席者(敬称略)

        前

    開始 →
    +---------------+↓
    |        |
    |    机   |
    |        |
    +---------------+
    ↑       ←

吉村o, 岩永, 岩室o, 小棚木, 高橋(徹), 村上
栗野, 亀井, 村山
門脇, 高橋(智), 石黒, 金井, 遠藤, 吉本o, 奥
岡沢, 根本

朗読者: 吉村, 岩室, 吉本
書記: 栗野

本 : 「アジャイルソフトウェア開発の奥義」

==

自己紹介
    >>> 略 <<<

==

p.433 から

==

26.1 proxy パターン

proxy パターンの適用 (図 26-2 p.423)

    proxy が二つの差を吸収する
        test から作成する
            order proxy は order と全く同じ振舞いをする事を想定

        # public メンバがあるが、これは気にしなくてもよい
        #    なんでもかんでも setter/getter を付けるには変
        #        => プログラムを複雑にしている

        # Q. 全てのメンバを private にし、インラインアクセッサを自動生成しては.. ?
        ID の生成 : 連続番号を作ればよい。

        proxy で、interface をつきぬけるような例外を投げる
            うっとうしい
                例外を Error にする ( try-cache が不要 )
                    # Q. 本当にこれで良いの ?

    proxy パターンのまとめ
        [欠] 適用が難しい
        シンプルな委譲モデルになるとは限らない
            委譲モデルの後に別の処理の実装が必要
        キャッシュを考慮する必要がある場合がある ( パフォマーンスの問題 )
            必要な場合だけ考える

        [利] 強力な機能を持つ
        モジュール間の切離しが可能
            例 : ビジネスロジックと DB の分離

            3'rd party Package の API と Application の分離
                Appl で、直接 3'rd API を利用すると..
                    後で、Package が更新されたら悲惨
                    分離するための layer が必要
                        => proxy

            JDBC の例

    Q. 「JDBC の場合スキーマが Appl から分離されていない」の意味が解らない
        A. Text の例では、確かに、DB に依存したコードになっている

        Q. 「逆転させる」
            A. 「依存関係逆転」のことでは
                Q. 具体的には ?
                    A. 26-8 を参照

    Q. ここでいう API って ?
        A. JDBC のことでは ? ( 見方によるが.. )
        A. DB という箱は p.438 の DB.java のこと
        A. Application は Data を渡すだけ、実際の構造は Appl が知らなくてもよい
        Q. 一番上のレベルでは確かに逆転しているが... 下の方では結局問題があるのでは ?
            # 設定ファイル等で、情報を外に追い出さないかぎり..
            A. ポイントは、「Product」という I/F の導入。他は、全てのモジュールが、これだけに依存する

    依存関係が Proxy に集中する
        => Proxy の作成そのものは、大変になってしまうが..
            問題がどこにあるかが解っていることは良いこと..

26.2 天国への階段
    依存関係を逆転させてくれるパターン ( Proxy と同様 )

    Q. クラス図が読めない..
        # 多重クラス継承ができる言語でないと実装できない。

    Q. 「プロダクトが自分自身をみつけてしまっている」って.. ?
        # 「侵害されてしまっている」の意味は ?
        A. ダイアモンド継承のために複数の継承の経路で、同じメソッドが見付かる

        [宿題] 原文をみる

        A. 仮想継承だと、一箇所にまとめられるので...

        A. 「Tree 構造になっていない」ってこと ?

    [利点] ビジネスロジックと DB 分離

    Q. 凄いキャスト
        A. 継承構造がみえない..
        Q. 実体はパーシステントプロダクト ? アセンブリ ?
            => 両方を継承していることを仮定している

        Q. 失敗するパターンは ?
            A. プロダクトの時 ( 0 が却ってくる )

    # R/W をパーシステントから切離す

26.2.1 天国への階段の例

    Q. 不死ってどうなる ?
        A. このコードを読んだ担当者が死ぬ.. ?
            自分で書いたコードが読めない..

    Q. 二重継承を防ぐには、仮想継承しなければならない
        忘れた時に何が起きる ?
        具体的に何が問題 ?
        プロダクトが二つあると何がいけない ?
            インスタンスが二つできる..
            Q. virtual をつけないと二重になる。
            Q. 下からみると、上に二つあるので..
            Q. キャストの仕方によって、違うものをアクセスしてしまう..

        Q. 結局、死にはしない.. ?
            A. 死ぬこともあるでしょう..

            [宿題] 死ぬパターンを作れたら作る

    Q. 「PersistentObject は .. 知っているようだ..」.. て..

    Q. 「private な virtual ?」
        なぜ、public/protected でない ?
        どうゆう意味があるの ?
            Q. 毎回実装 ?
                だから Header/Fodder のみ

            [宿題] 上記を試してみる (実装のバリエーションが欲しい..)

        A. C++ の言語仕様の Document の PDF が公開されている
            検索もプリントもできないが.. View Only
            Q. なんとか Hack できない ?
                cf. 「グラーバ」PDF Soft
                自分で viewer を作れば何とでも ..
                Text 化はできるが..
                画像かも..
                    OCR で..
                    Screen OCR では ?
                Q. 暗号化されている ?

    Q. private は親クラスの実装を再利用させない仕組

    Q. これはリスコムを守っていない

    Q. そもそも、この名前がよく解らない (何が天国..)
        A. 扉の絵の映画の中にオチあるのでは ?
            マーチンの本には書いてあるのでは ?
                本はない.. Web にあるかも..
                    多重継承の良い使い方
                        aspect/mix-in 的な多重継承

                        # mix-in をするならば、mix-in を使って欲しい.. 多重継承を mix-in の代わり使うのは問題では..
                        #    歴史の問題では.. (mix-in はなかったんでしょう..)

        Q. 言いたい事は結局、「パーシステントにできる」ってこと ? そのためにここまでやる ?

    Q. 依存関係が逆転している
        A. パーシステントにいれなければならなくなる..


26.3 データベースと組合せることができる他のパターン

26.4 結論
    
27. ケーススタティ

    Q. java の選択は本当 ?
        A こじつけでは

        A. realtime に対応した VM もある。

        Q. VM の移植問題はないの ?

        Q. System がないのに何故、言語が先に決る .. ?
        Q. C で書けない ?
            A. 低レベルのコードが大変なのでは ?

        Q. まず、評価用ボードがないと始まらないでは ?
            java の動くボードにする
                soft の開発工程を減らすために hard に制約を..
                   理論上の話..

==

# 午後

# p.497 を目標

## 読物っぽいので、進みそう

    Q. 後ろの付録は何時読む ?
        A. 短いので今読む。

    [誤殖] p.488
         「#11:相対温度船さ」=> 「相対温度センサ」
         「#12:風速船さ」=> 「風速センサ」

    Q. 27-5 の図が良くわからない
        # Sequence 図
        A. 確かに、このような書き方はないが、解ればよい.. ?

        Q. Sequence 図の方が理解りやすい ?
        
        Q. 図 27-4 での点線は、正い ( 依存関係 ? )
            # なぜ、「点線?」
            #    Object 同士は関係ないが、class に関係はある
            A. 初期化の時に関係している
                Q. 初期化の話がどっかで..
                    A. Factory モデル/自分で、? /インジェクション ?

        Q. スケジューラが read を投げているのは ?
            A. 確かにトリガーという気分ですね..
            Q. read からは何時帰ってくるの ? ( 遅くない ? )
                A. スレッドにするんでしょう..
                    Q. オブザーバパターンは、マルチスレッドを仮定しているのでは ?
                        A. かならずしも.. 特に今回の場合は、時間に問題ないので..

        Q. 「1分間に一度」という記述がない
            A. ハードと関係があるので、記述できない ?
            A. java でも、そこは native method
                # 1.0 なら Posix, 2.0 なら windows mulit media ..

    [誤殖] p.461 l.6 「それ観察」 => 「それを観察」

        Q. 27-6 図 : Trend から引かれている「点線」は ?
            A. Trend の計算に Pressure が必要だから、関係が生じる
            A. 点線は、
                1. リファレンスを内部に保持しない
                2. でも、何らかの形で、他のクラスを利用する
                という意味

                Q. 点線だとコンパイル時に必要 ?
                    A. Yes

        Q. scheduler は read を呼ぶ ?

        A. 今は、設計が固まっていないので、あまり議論しても..

        Q. Ovserver と Senser の関係は、責任をもって合せる必要がある ?
            A. Yes


    Q. 図 27-7 ?
        A. 図の下の本文の説明を読んでから..
        A. 要は名前(設計)が変った
            Scheduler => AlarmClock

        Q. 図中の ◯+の記号の意味は ?
            A. インナー (無名) クラスとして登録
            右側の ( <> は java の無名クラス (AlarmListener を実装している) を意味 )

    Q. AlarmClock の実装はどこ ?
        A. 簡単な Class なので..
        Q. せっかく java なので、実装が知りたい
            A. ハードにデペンドしているから書けない ?
            Q. 実際には、他から tic() で、kick されているだけなので、ハードには、関係なさそう。でも、非同期か同期かは決っていないのかも..

    Q. <> というのは ?
        A. java 固有では ..
        Q. 他の言語でも在り得るのでは ? ( Lisp の LAMBDA 式とか.. )
            A. anonymous & internel という組み合わせ..

        [宿題] 実装を、最後まで行う
            OS 別にがんばろう..
            Q. AlarmClock が大変 ?
                A. java なら簡単かも
                    cf. util.timer class がある
                    タイミングを指定して呼出してくれる
                    [宿題] API を紹介

            Q. C 言語だと大変 ?
                A. OS 組み込み ? POSIX にある ?
                A. まあ、java なので、

        Q. タイミング(定期実行)を考えると OS まで考えないと..
            A. 遅延を許せばある程度は大丈夫
                ただし、永続化も考える必要がある
                    # プロセスが死んでいたら、再起動する仕組とか..

                Q. サマータイム問題もある..
                A. CORBA, EJB の Timer Service を使えば

                Q. 信頼性は ?
                    A. 大問題

        Q. cron は、OS によって実装 ( サマータイムの扱い ) が異る
            A. HP は一回必ず。Sun は、呼ばれたり、二回呼ばれたり..

        Q. サマータイムって、結局.. ?
            A. java の class が内部で処理しているから..

        Q. 6/60 24:00 の次は 7/1 の 1:00 になってしまうが.. ?

        Q. サマータイム問題は、解決済の問題
            A. アメリカ人は、ASCII しか考えない, 日本人はサーマータイム/タイムゾーンを考えない
                A. Localize をすればどうせ..

            ([宿題?] サマータイム問題を考える.. ??? )

==

# 10 分休憩

==

    [誤殖] 27-1 ( 27-2 も.. )
        5 行目の「;」の後に 「())」が必要
        13行目の最後に「;」が必要

    Q. 「)」を「こっか」と呼ぶの ?
        A. Local Rule

    Q. UML では 「1.0」 と表記されている物が list 27-1 では 1_0 になっているけど、
        A. どっかの tool が処理してくれる

        Q. 全角空白で、こける !!
            A. コーディング規約で頑張る ( IME で半角のみにする )
            A. 全角空白を「とうふ」表示するエディタを使う。

    Q. 27-12 : Code を読んだほうが簡単
        A. もっと綺麗に書かないと理解りにくい

    Q. これでは、AlarmClock が StationKit に depend するので..

    Q. StationTookKit って何物 ?
        A. SunToolKit との関係があるのでは.. ?
            Q. new する場合としない場合があるけど..

    Q. p.470 の頭の部分がよくわからない..
        A. 27-14 で、main が weatherStation に入っていたとすると、問題だと述べているらしい。

    Q. 図 27-15 の <> って何 ?
        A. 「Monitoring Screen は<> としてWeather Station Componet を利用している」の意味

    Q. 実線と点線の違いって何 ? (図 27-16)
        A. パッケージ間であれば
            実線:構造的に、かたく結びついている
            点線:関係はあるが、緩やかな結びつき
        Q. main はパッケージではないが..

    Q. NVRAM って ?
        A. Non V.. (揮発) RAM

    Q. list 27-7 ?
        A. 名前で、保存や復元ができて、ついでに、名前 list も取れるようなものと理解すれば十分では..

    Q. midnight と update の呼出すタイミングは ?
        ひょっとしたら、逆になるかも ?
        # update の引数に date がないので..
        # 困らない ?

        A. 実装しだいか.. ?


    Q. 日の切り分け ( 0:00 ) の最低最高温度は、二日で共有される
        A. 業務要件で定める
        Q. やっぱり、read で date をやり取りしたい..
            A. センサーは、時間と切離したい。

        Q. ハードによって、どのような情報が来るかが解らないと..
            A. 実際にやってみたけど、やっぱり、時間がない
                確かに、時間がずれるが、気にしない..

            A. Application が時間にシビアでないので..

        Q. update に、time を持たせたい
            A. Sensor が時計をもっていると色々不便
            A. Simple & 誤差に対する許容の結果の判断

            A. GPS は別扱いかも..

            A. 単一責任
            Q. value() に引数がない方が..

            Q. 使う側の重用度
                A. Sensor としては、それだけで十分

        Q. update のタイミングだけでデータを保存していたら、あちらこちらで欠落が..
            A. どっかで補間する ?

==

# 休憩

    Q. 結局、時間ってどうやって决めるの ?
        A. セシウム時計を..


==

27.2.2 HiLo アルゴリズムの実装

    Q. Scop という名前のクラスの意味は ?
        A. 後で捨てるクラス
            パッケージスコープを解決するに、一次的に導入したもの
            グローバル変数の置場 ?
            パッケージに入るグローバルを収納するための入れ物 ?

    [誤殖] 図27.11 は DataToolkitImpl() を new すべき

==

6 部 ETS のケーススタディ

28 章 Visitor パターン

28.2 Visitor パターン
    デュアルディスパッチを使う
        ポリモーフィズムを使ったディスパッチを二度行っている

    Q. 実行時間が速い ( 何に比較して ? )
        A. if 文と比較して速いのでは ?
        # cf. 28.2.1 を参照

        Q. 関数行列って ?
            A. 関数 Ponter の 2 次元配列を作って、table lookup で呼出す。

    Q. 90 度回転って ?
        # acyclic では 180 度といっているが..


==

次は p.500 28.3 から


[ 戻る ]