読書会(Java言語で学ぶデザインパターン入門)第4回議事録

[ 戻る ]


======================================================================
 読書会(Java言語で学ぶデザインパターン入門)第4回議事録
 日付:2002/02/23
 場所:三田図書館集会室
 課題図書:「Java言語で学ぶデザインパターン入門」(結城浩著)
 範囲:第13章Visitorパターン(P.206)
                         〜第17章 Observer パターンまで
 読み手:午前=金井 午後=高橋
 議事録:鈴木
 出席者: 高橋(徹)/高橋(智)/倉村/鈴木/村上/山城/福島/
                 東宮(とうみや)/百瀬/金井/根元/秋元/西岡/石黒
                 (順不同、敬称略)
 スケジュール:
         1.読み手/ 書記
         2.自己紹介
         3.読書(10:00-11:45)
         4.昼食
         5.読書(13:00-16:45)
         6.打ち上げ

======================================================================
[10:27:08]----------------------------------------------------
■13章 Visitorパターン
○問題13-1
 ・継承して作ったほうがいいのか?
 ・リファクタリングして再利用するのがいいのか?
 ・最初から作るのが良いのか?
 3つくらい戦略がある。

○問題13-2
 getSizeメソッドを書き換えなさい。
 その時に、SizeVisitorクラスを作りなさい。
 以上の2つをやらなければいけない。
 →DirectoryクラスのgetSizeをオーバーライドする。
  アルゴリズムを別クラスにまとめる。

[TOPIC]
○結城パターン
 本文の説明に出てくるクラスには必ず「問題」があって、
 問題までをみて、解決しておかないと
 よくないサンプルを利用することになってしまう。
 →技術書としては完成されたサンプルでの解説が欲しい。

[11:26:28]----------------------------------------------------
■14章 ChainResponsibility
○このパターンのメリット
 このパターンはたとえば、
 障害系の処理を行うのを処理するのに適している
 Troubleクラスが障害コードを持っている。
 Supportクラスのサブクラスたちで、
 もらった障害コードを自分で処理できるか判断している。
 Supportクラスはサブクラスたちを管理してやり、Troublueを次々とサブク
 ラスにわたしてやって処理できなかったら、次の処理へ、
 処理できたら#resolveを返す。

○NoSupportクラスの存在意義は?
 →問題の解決の処理はしないけれど、
 画面で処理中フラグを立てるなどの処理を実装するのに向いている。

○問題14-1
 問題が漠然としている

○問題14-2
 使い勝手を考えましょうという問題だろうか。
 Chain of Responsibilityによってフォーカスの並びがかわるから、
 それをコントロールするのだろうか。

○問題14-3
 誰がコールしても良いかという問題。
 親クラスだけが呼べるという前提を作りたがっている。

○問題14-4
 getNextでNULLになるまで、whileで回すのだろうか。
 答えはfor文
 あんまり気持よくない。一番先頭にいるオブジェクト以外は
 このメソッドいらないから、うつくしくないように感じる。

[13:35:51]----------------------------------------------------
■第15章 Facadeパターン 
Q.Facadeパターンはたくさんの低レベルのクラスをひとつにまとめて、
  入り口をひとつにしましょうというパターンで、
  Commandパターンとどう違うのでしょうか。

A1.Commandパターンはたくさんのクラスをまとめているわけではない。
  オブジェクトを渡して、渡した先で、それを居れて実行する。
  Facadeはオブジェクトを渡すわけではなくて、
  一個、メソッドを呼ぶだけで、裏で詳細処理をしてくれるイメージ。

A2.Commandパターンは専門の料理人を裏でいろいろ抱えている。
  単純に一個の制御を発行しているケースが多い。
        (Commandはコックとレシピ(コマンド)だけ。
  登場人物がたくさんいなくてもよい、とも言える)
  それに対し、Facadeパターンは10人の料理人に、役割分担をし、
  役割分担の順序を決め、制御している人が一人いる。
  FacadeとCommandは一緒に使うケースがあっていいかもしえない。

ヒント.
 J2EEパターンのSessionFacadeパターンを見ると良いかもしれない。
 とりあえず、Commandパターンは抽象化していて、レベルも実装が違う。


○P232.Windowsのコントロールパネルの設定のよう。
 複雑になってくるとありがち。

○問題15-1
 単にpublicを外せというだけ。
 インナークラスとか名前無しクラスにするという手もある。

○問題15-2
 なぜJavaマークがついてるのだろうか。

[14:34:06]----------------------------------------------------
■第16章 Mediatorパターン
○この章にあるダイアログの例文について
 このダイアログは良い題材。初学者に向けて。
 switchケースでどんどん増やして行って破綻するパターンに陥りがち。
 誰もがそうして一個にまとめることを学習できる。

○コードの書き方
 それぞれのチェックボックやテキストにボタンの表示非表示を
 制御するコードをばらばらに置くと、
 イベントハンドラが呼び合って、ハンドラが返って来ないことがある。

○ P249.//Listnerのセット
 すこしトリッキーに見えるけれど、これをやると関係が明示されるから?

○P249.斜線部分
 Frameではなく、独立したクラスにしてもよいのでは?
 ロジックの部分を脇にサンプルとして作ってほしかった。

○問題16-1 
 4文字以上という表現のとき、
 4<=と書くか、3<と書くか?
 4と書いた方が4文字MAXというのが明示的で良い。
 ならば1桁以上有効の場合は
 0<ではなく、1<=と書く?

 いや。0<としておくと、0に存在無しという意味が
 明示されるのでこれでよいのではないか。

[15:41:01]----------------------------------------------------
■第17章 Observer 状態の変化を通知する
Q.RandamGeneratorとNumberGeneratorが2段階になっているけれど、
  意味があるのか?
A.Observerの数を発生させるところと、通知するところを分離させている。
  RandamGeneratorの他に、SequenceNumberGeneratorや、
  IncrementalNumberGeneratorなどを追加してゆくことができる。

○IteratorまわすところがSynclonaizedでもいいと思う。
 →マルチスレッドでObserverの管理は難しいだろう
○NumberはStringでもいい。するとgetNumberというクラスが破綻する
○本当に使うとするとしっかり管理しないと大変そうだ

○P.266 java.util.Observerインタフェース
 Observerパターンはすでにあるものをつかうほど複雑じゃないので、
 手で作るケースが多い

○Observalbleクラスの中身
 ソース見ても対した量ではないのではないか?
 SUNの失敗作?歴史的経緯のように思える。
 使えないから、みんな専用に作ってる。
 ListnerはObserverに似ているけれど、使ってない。
 考え方は使われるけれど、アプリケーションに強く依存されるので、
 使わない。


[ 戻る ]