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

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

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

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

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

[11:26:28]----------------------------------------------------
■１４章　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]----------------------------------------------------
■第１５章 Facadeパターン　
Ｑ．Facadeパターンはたくさんの低レベルのクラスをひとつにまとめて、
　　入り口をひとつにしましょうというパターンで、
　　Commandパターンとどう違うのでしょうか。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[ 戻る ]