[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfriends] 読書会議事録(2)
議事録作成プロジェクトから帰ってきました。
とりあえず現地で入力したままを投稿します。
=======================================
第1回
日時: 1998年12月12日(土) 10-16
場所: 午前 ジュンク堂書店9階喫茶室
午後 カラオケボックス
出席: えんどう、高橋(智)、高橋(徹)、野村、さいとう、布留川、野口、岸田、
東海林、水野
序文
まず、序文では全体的な構成が書かれている。
この本の全般的な傾向としては、用語が定義なしに登場して、
あとの方で定義らしきものが書かれることが多い。
序文の中にも継承と対比して「コンポジション」という用語が登場するが、
「コンポジション」の定義について疑問が出た。
「コンポジション」とは何かについては、p.38に若干の説明がある。
(1対1の場合はコンポジションを使わないとあるがなぜなのか？
原書第2版では以下が削られている。
「ただし通常は..」から「..作用します」まで。)
「コンポジションは、追加のオブジェクトに機能を委譲することによってオブ
ジェクトの責務を拡張します。」
この説明を読んでさらに疑問が出た。
・「責務を拡張」するとは具体的にどういうことなのか？
・「委譲 (delegation)」と「関連 (composition)」はどう違うのか？
また、「継承」という用語についても定義されているわけではない。
たとえばこの「継承」とは、Javaにおける extends のことと同義なのだろう
か？
ここで話題は継承に移っていった。
「継承を使わないと書けない場合もあるのではないか、たとえば
java.awt.Frame や java.applet.Applet のサブクラスを書かないとGUIプログ
ラミングできないのでは」という意見が出た。
これに対しては、
「ライブラリーとアプリケーションは分けて考えたほうがよいのでは」
「設計段階と実装では思想を変えたほうがよいのでは」
という意見もあった。
継承については「差分コーディングのための継承は必要ではないか」という意
見も出た。
第1章 例題による設計
この本は1章から5章まで、
ビジネス・アプリケーションの例として航空会社の航空機レンタルシステム、
リアルタイム・アプリケーションの例としてセンサーのモニタリングシステム
の2つの例をもとに段階を追って書かれている。
この章の最初では、「5つの主要なアクティビティー」について説明されてい
る。
「アクティビティー」の定義について疑問が出た。「アクティビティーであっ
て手順ではない」とあるが、具体的に何なのか？
辞書には activity [名] 活動; 活気; 仕事.(三省堂書店 表音小英和) とある
が、
「作業」とでも言う意味なのか？
・システムの目的と機能を識別する
・クラスを選択する
・UIをスケッチする
・シナリオをもとに動的な側面を見極める
・オブジェクトモデルを構築する
ここで「UI」という略語がいきなり登場している。
p.1, p.8に「ユーザー・インターフェース」の略であることは書いてあり、
あとの方で「PD(Problem Domain:問題領域)」と対比して登場するので「ユー
ザー・インターフェース」のことではないかと分かるのだが、ちょっと不親切
ではないのか。
(「問題領域」についてはp.5「特定のアプリケーション分野に固有に登場する
クラス」と書いてある)
それから「例題」に関してだが、
航空機のレンタル業務や、センサーのモニタリング業務についての知識が無い
者には、
何を目的としたシステムなのか、取り扱う対象にどんな種類のものがあるのか、
よく分からない。
たとえば、あとの章で書かれている「乗客」は分かるが「代理人」が何をする
のかよく分からないとか、普通のセンサーと「リモートセンサー」の違いとか。
この点についての説明は特に無い。
UIとPDに関して、MVC (Model-View-Controller) の話しが出た。
「この場合、PD がモデル、UI がビューに当たるが、コントローラーはどこに
あるのか分からない」という疑問だったが、「ただ見えるものがビュー、モデ
ルとビューをつなぎ、処理をつかさどっているものがコントローラー」という
意見が出された。
p.8の「UIのスケッチ」では「一次選択肢」と「リスト」というものが登場す
る。
「リスト」は分かるが、「一次選択肢」とは何なのか？
「リストの中から一つ選ぶ」ということを言いたいのか？
「最初に選ばれるもの」という意味なのか？
「一次」「二次」「三次」はただ選ぶ順番なのか？
p.11 に「シナリオビュー」の図が登場する。この図の読み方はp.12に若干の
解説がある。p.205 にも説明図がある。
p.16「コンポーネント」という用語が登場する。
ここでも「コンポーネント」について特に説明は無い。
辞書によると「component [名] 構成要素〔部分〕; 部品; 成分.[形] 構成す
る.」とあるが、
とりあえず「部品」と考えておけばよいのか？
p.17の図では、Person と Passenger が 1-n の接続関係になっているが、こ
れが「コンポジション」の関係なのか。
また、p.17 のUML と Peter Coad 表記の違いについて、UML はクラス図だが、
Coad 表記の図ではクラス図とインスタンス図を兼ねている。
また、1対nの表記の、1とnの位置がUMLとCoad表記は逆になる。
オブジェクトになったつもりで見ると、n個を持っている方に 'n' を書くのが
自然なのではないか。
p.21-22 にオブジェクト接続の説明がある。
p.23 「UIコンポーネントのためのオブジェクトモデル」の説明の中に、「接
続はテキストによって示されていいます」とあるがどういうことかという疑問
が出た。
「これはネーミング・ルールのようなものを使って接続関係を表している」と
いう解釈になった。たとえば「Airport」という問題領域オブジェクトに対し、
「AirportUI」というUIオブジェクトが対応する。
オブジェクト接続の線について、p.204の図を見ると、外側のオブジェクトか
ら引かれている接続線と、内側のクラスの太線から引かれている接続線がある。
これはどのように使い分けているのかよく分からなかった。
昼食は焼き肉定食、終了後の宴会はにんにく料理であった。
第2回
日時 1999年1月23日(土) 10-16
場所 タイムインターメディア (新宿スパイアビル B1F)
出席: えんどう、高橋(徹)さん、野口さん、東海林さん、高橋(智)さん、さい
とうさん、石黒さん、木下さん、酒井さん、金山さん、
p.25からはセンサーのモニタリングシステムの例の説明だが、
この記述では何のためのシステムなのかよく分からなかった。
p.29での「問題の間隔」とは何かという疑問が出た。
原書(第2版)を読むと、問題が発生してから修復するまでの時間間隔のことの
ようだ。
これについては、MTBF (部品が稼動してから壊れるまでの稼働時間の平均値)
というものがシステム解析で重要な場合があるという話しが出た。
p.34 のリスト 1-4 で、メソッド addRepeater() の引数が Object 型になっ
ているが、
コンパイル時に型チェックができないのでこの設計は間違っているという意見
が出された。
Peter Coadは、メソッドの引数にはプリミティブ型 (int, doubleなど)や
String や Obeject 型のような汎用的な型を使うことを推奨している。(p.172)
たしかに後々の拡張を考えると、特定のクラスに制限しないほうが便利である。
反面、コパイラーによる静的型チェックが利用できないデメリットがある。
第2章 継承ではなくコンポジションを利用した設計
前回も出たが「コンポジション」とは何かという疑問がある。
p.38の最初に書いてはあるのだが「責務を拡張」の「責務」とは何かという疑
問があった。
CRCという設計技法があるそうだ。
各自がオブジェクトの気持ちになって、メッセージをやりとしして分析する設
計技法のようだが、このとき自分が知っていなければならないこと、自分がや
らなければならないことの範囲がはっきりする。これを「責務」と呼んでいる。
クラス
---------------------------------
責務 | 協調
(Responsibility) |(Coraboration)
p.41 継承のリスクで、「スーパークラスとサブクラスとの間ではカプセル化
が弱い」とあるが、具体的にどんな弊害があるのか？
スーパークラスを変更したときにすべてのサブクラスに変更が波及するが、
すべてのサブクラスでの変更を検証したり、それによる影響を修正したりする
必要が生じる。
p.44の図2-7に人の絵が書いてあり、頭から線が延びて四角い箱のよなものに
つながっている。
この箱のようなものは帽子を表しているのだが、絵が簡単すぎてなんだか分か
らない人もいた。
p.46で継承を使うかどうかの5つのチェックポイントが提示されている。
5つ書いてあるが、どれも結局は「is-a」の関係かどうかで判断できる、とい
う意見があった。
これに対しては、「is-a」かどうかすぐ分かる人は良いが、どんなときに
「is-a」か判断するためのチェックポイントなのではないかという意見もあっ
た。
「ユーティリティークラス」とは、「PDでもなく、UIでもない便利なクラス」
(Vectorとか)
p.50 コンポジションと継承を両方使用する場合
ここで Decorator パターンについての話題が出た。
Decorator パターンは重要なようである。
後日、Decoratorパターンを使った改良案のソースコードの投稿があった。
p.56-57のセンサーの例で、リモートセンサーには値を読み出すメソッドがあ
るが、センサーにはない。
センサーは値を読み出す必要が無いのか？
p.59 Thread の例があるが、Thread はユーティリティークラスなので継承せ
ず、
p.61 のリスト 2-5 では、Runnable を implements したクラスを書いて、
そのクラスの中で Thread を2つ内包している。
Thread を継承してしまうと Thread を2つ持つことはできない。
JavaHouse MLで、「Thread を継承するべきか、それとも Runnable を
implements したクラスを書くべきか」という議論があったが、このソースは
それに決着をつけるようなものではないかという意見が出た。
p.61 で Applet の例があり、Appletは継承に適しているという結論だった。
Appletのメソッドをオーバーライドする例があるが、
p.64 で Observable の例があり、Observable は継承に適していないという結
論が出た。
昼食は喜多方ラーメン、終了後の宴会はインドシナ料理であった。
第3回
日時: 1999年2月20日(土) 10-16
場所: 神田
出席: えんどう、野村、高橋(智)さん、布留川さん、天野さん、木下さん、金
山さん、石黒さん、酒井さん、岸田さん、野口さん
p.70 にある「メソッドシグニチャ」とは何か？特に説明は無い。
(抽象的な意味なのか、引数と戻り値の仕様という意味なのか？前者のよな気
がするが...)
p.72の上のほうに、interfaceの利点についてごく簡単に説明してあるが、こ
の利点はとても重要である。(プラグ接続性)
「コンポジション」の訳語として、戸松「Javaプログラムデザイン」には"合
成" "複合"が使われている。
p.75 4つの主要なコンテキスト
・リピーターを抽出する
・プロキシーを含めて抽出する
・類似のアプリケーションのために抽出する
・将来の拡張に備えて抽出する
p.76 では、繰り返し登場するメソッドをインターフェースとして抽出する戦
略が書かれている。
これに対しては、あらかじめクラスの果たす役割がはっきりしていれば、それ
をインターフェースとして抽出できる。
既存のクラスから抽出するのはやり方が間違っているという意見が出た。
p.80のリスト3-2では、1つか2つのメソッドを独立したインターフェースとし
て抽出しているが、
共通の役割を持つインターフェースはある程度まとめるのが普通だし、このや
り方にメリットがあるのかという意見が出された。
これに対しては、
たとえば大画面のワークステーションで使えるCaseツールで、1メソッド1イン
ターフェースの細かい規模のinterfaceを操作して分析/設計できるとしたら有
効かもしれないという意見が出た。
あと、インターフェースを作るときに、自分がインプリメントするのではなく、
他のクラスに期待する役割として考えるのではないか、これなら分かる、とい
う意見があった。
p.85 抽出する例はあるのだが、使う例が無い。
p.77 「画面のスペースを使いすぎて見にくくなります」とあるが、原書第2版
では「class daigram」と書いてある。
「プロキシを含めて抽出する」の「プロキシ」の定義はp.90にある。
「別のオブジェクトに代わって質問に答え、便利なインターフェースを提供し
ます」
p.95 にまとめがあるが、この部分に著者が言いたいことが書いてある。
「類似したアプリケーションのために抽出する」と「将来の拡張に備えて抽出
する」例があるが、この例だけでは両者の違いがよくわからない。(例が悪い?)
--
えんどう やすゆき <yasuyuki@xxxxxxxxxx>
http://www.javaopen.org/jfriends/ (Java互助会ホームページ)