Visitorパターン○問題13-1・継承して作ったほうがいいのか?・リファクタリングして再利用するのがいいのか?・最初から作るのが良いのか?3つくらい戦略がある。○問題13-2getSizeメソッドを書き換えなさい。その時に、SizeVisitorクラスを作りなさい。以上の2つをやらなければいけない。→DirectoryクラスのgetSizeをオーバーライドする。アルゴリズムを別クラスにまとめる。問題までをみて、解決しておかないとよくないサンプルを利用することになってしまう。→技術書としては完成されたサンプルでの解説が欲しい。障害系の処理を行うのを処理するのに適しているTroubleクラスが障害コードを持っている。Supportクラスのサブクラスたちで、もらった障害コードを自分で処理できるか判断している。処理できたら#resolveを返す。画面で処理中フラグを立てるなどの処理を実装するのに向いている。○問題14-1問題が漠然としている○問題14-2使い勝手を考えましょうという問題だろうか。Responsibilityによってフォーカスの並びがかわるから、それをコントロールするのだろうか。○問題14-3誰がコールしても良いかという問題。親クラスだけが呼べるという前提を作りたがっている。○問題14-4getNextでNULLになるまで、whileで回すのだろうか。答えはfor文あんまり気持よくない。先頭にいるオブジェクト以外はこのメソッドいらないから、うつくしくないように感じる。入り口をひとつにしましょうというパターンで、Commandパターンとどう違うのでしょうか。A1.Commandパターンはたくさんのクラスをまとめているわけではない。オブジェクトを渡して、渡した先で、それを居れて実行する。一個、メソッドを呼ぶだけで、裏で詳細処理をしてくれるイメージ。A2.Commandパターンは専門の料理人を裏でいろいろ抱えている。単純に一個の制御を発行しているケースが多い。(Commandはコックとレシピ(コマンド)だけ。役割分担の順序を決め、制御している人が一人いる。FacadeとCommandは一緒に使うケースがあっていいかもしえない。ヒント.J2EEパターンのSessionFacadeパターンを見ると良いかもしれない。Commandパターンは抽象化していて、レベルも実装が違う。○P232.Windowsのコントロールパネルの設定のよう。複雑になってくるとありがち。○問題15-1単にpublicを外せというだけ。インナークラスとか名前無しクラスにするという手もある。○問題15-2なぜJavaマークがついてるのだろうか。Mediatorパターン○この章にあるダイアログの例文についてこのダイアログは良い題材。switchケースでどんどん増やして行って破綻するパターンに陥りがち。誰もがそうして一個にまとめることを学習できる。○コードの書き方それぞれのチェックボックやテキストにボタンの表示非表示を制御するコードをばらばらに置くと、イベントハンドラが呼び合って、ハンドラが返って来ないことがある。P249.//Listnerのセットすこしトリッキーに見えるけれど、これをやると関係が明示されるから?○P249.斜線部分Frameではなく、独立したクラスにしてもよいのでは?ロジックの部分を脇にサンプルとして作ってほしかった。○問題16-14文字以上という表現のとき、4<=と書くか、34と書いた方が4文字MAXというのが明示的で良い。1桁以上有効の場合は0<=と書く?いや。0明示されるのでこれでよいのではないか。意味があるのか?A.Observerの数を発生させるところと、通知するところを分離させている。RandamGeneratorの他に、SequenceNumberGeneratorや、IncrementalNumberGeneratorなどを追加してゆくことができる。○IteratorまわすところがSynclonaizedでもいいと思う。→マルチスレッドでObserverの管理は難しいだろう○NumberはStringでもいい。手で作るケースが多い○Observalbleクラスの中身ソース見ても対した量ではないのではないか?SUNの失敗作?歴史的経緯のように思える。使えないから、みんな専用に作ってる。ListnerはObserverに似ているけれど、使ってない。