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

======================================================================
Java言語で学ぶデザインパターン入門第5回議事録
日時: 2002/03/30  10:15 ～ 16:45
場所: 太田区民プラザ第3会議室
範囲：第18章Mementoパターン(P.269)
                         ～第21章　Proxyパターンまで
参加者: 天野福嶋金井東宮中田鈴木武川村上海内
        布留川高橋(徹) 石黒高橋(智) 越地、百瀬 (敬称略、席順)
読み手: 午前中田午後福嶋
議事録: 武川

スケジュール：
         1．自己紹介
         2．読み手/　書記の決定
         3．読書（10:30-11:45）
         4．昼食
         5．読書（13:00-16:30）
         6．自己紹介
         7．打ち上げ
======================================================================

■はじめに
久しぶりに出席したのですが、スレッド・プログラミングの時代からは
考えられない程、人数が非常に増えていて活気がありました。
びっくりしました。また、本もわかりやすく、話もはずんでよかったです。

■始まる前の雑談
・Netサーバってなに
→Windows2000 サーバ以上のOS の後継OSです
http://www.microsoft.com/windows.netserver/evaluation/overview/default.asp
に説明が載ってました。XPサーバっていってくれたほうがわかりやすいのに。。。

■ 18章 Mementoパターン
P.269 扉絵
・章の扉絵はパターンのイメージ図を書かれている。18章はちょうちょが、自分の
成長状態の写真を貼っている絵。でも、写真じゃundoできないと思うけど。。。。

P272 Fig 18-1
・ Mementoクラスのフィールドやメソッドに#がついているが、これはどういう意味か?
→protectedスコープの意味だが、UMLではJavaのパッケージスコープをあらわす記号が
ないので、これをつかっているのではないか? 1.4では~になるらしい(宿題)。

・Gamerクラスのbet,createMemento,restoreMementoは、+をつけないといけないはず。

P.274 Gamer.java
・Mementoクラスのmoneyにgetterが存在するのに、なんでフィールドにアクセスするのか?
→後で説明があった。narrowインターフェースとしてのgetter、wideインターフェース
としてのフィールドということらしい。

・このゲームは終わらないのではないか? 0チェックしていないからmementoしなくても
betを永遠に呼びつづけることができる。

・ Mementoクラスのコンストラクタでフルーツも一緒に渡すほうが綺麗ではないか?

P275 Main.java
・MementoクラスをMainクラスに見せる必要がないのか?
→undo,redoの処理を対象オブジェクトの外に出したい場合があるのではないか。
例えばgamerクラスか複数あって、同時にundo、redoしたい場合などは、
gamerを呼びだしているクラスがundo制御をまとめられるので、便利ではないか?

・複数ゲーマーが複数の状態をもつような状況では、どういう風にMainを書くの?
→宿題

・CADの会社で働いたときの研修でCADを作る研修で最後にundoの機能を作ったことがある。
そのときは、現在の状態(図面)は重すぎるので、各操作を保存して、その逆操作をすることで、
undoした。

・上記のようなundo処理では、commandパターンとmementoパターンを組み合わせるパターン
がよくつかわれる。

P.279 Fig18-4
・Mementoのメソッドとインターフェースが逆。

P.278 wide interface,narrow interface
・この言葉はこの本での定義か?
googleで narrow wide interface design pattern で検索したところ30700件見つかったので、
デザインパターンでの標準的な言葉のようです。ちなみに検索の一番トップは、
"Memento Pattern"でした。

P.283 演習問題
・シリアライズの作成については注意する必要がある。Effective Javaに詳しい話がある。

P.434 演習問題回答
・DeflaterOutputStream はzlibライブラリを使っているけどバッファオーバフローの問題ないのかな?
→zlib1.1.3まではバッファオーバフローではなく、2重フリーの問題があるそうです。
→調べてみましたがよくわかりませんでした。DeflaterOutputStream.javaはDeflater.javaを
呼びだしていて、この中でnative callを行なっています。というわけでzlibを使用していて
問題がありそうな気がしますが。。。。
→http://www.gzip.org/zlib/advisory-2002-03-11.txtを読む限りでは、不正なデータを作って
zlibライブラリに渡した場合、エラーが起こると書いてあるように読める。
2重フリーした場合にエラー処理を勝手に走らせることができないから大丈夫ということなのかな?
でも、DoSは出来るとおもうけど。。

■19章 State

p.290 List19-3
・メソッドに public abstract と書いている意味は?
→ 書かないのと同じ意味だが、言語仕様書では書かないほうがよいという話がどこかに書かれて
いたと思う。

p.293 Context.java
・Context.javaにsetClockが存在するのに、State.javaのdoClock()は、hourの引数を持つのか?
contextで一緒に渡せばいいのではないか?
→インターフェースの方向が違うから渡しては駄目なのではないか?
→Context#setClock以外のメソッドは、stateから呼ばれるメソッド定義なので、Context#setClockが
Contextのインターフェースには含まれるべきではない。
→Contextを継承するインターフェースで、setClockを定義するのがよいだろう(EJBなどではそうなっている)で、
全てのインターフェースを定義したクラスを作成し、そのクラスをdoClock()の引数に渡すようにすればよい。

P.297 SetFrame.java
・setClockでjava.util.DateFormatとかは使わないのか?
→重くなりそうだし、単純な処理だから必要ないのでは?

P.299 Main.java
・Threadクラスを継承する必要はない。

P.298 Fig. 19-4
・ステートパターンだと制御が複雑になる感じがする。
→if文が沢山あると複雑と感じるのがオブジェクト指向な人と、
  ソースが上から下に流れないと複雑と感じる処理指向な人の違いかもしれない。
→画面とロジックという切り分けでみれば結構わかりやすい。

・Stateインターフェースの変更があると変更が大変ではないか?。
→Abstractクラスをインターフェースと実装クラスの間にかますことで、インターフェースの変更の影響
を最小限にすることができる。

P.302 4段落目
この2点を読んでうなずけないんですけど。。。
→1点目でインターフェースを定義して、2点目で対応する状態のクラスを書くということ、この2点が対比
されるというわけではない。

・ステートが多い場合のコード書く場合の対処として、コードを生成するプログラムを記述するという手もある。

P.304 3行目
・実行時に....の意味は?
最後のelse文に例外を出すようにすれば、存在しないステートの場合を検出できる。

P.306 問題19-1
・ SafeFrameがFrameを継承する必要はないのでは?
・ C#で多重継承は出来るのか(宿題)
→出来ない。http://www.csharphelp.com/archives/archive101.html

P.306 問題19-4
・非常時を解除するコードはどうかかくの?
→
1. stateインターフェースを変える案
2. SafeFrameで状態を強制的に変える案
などがある。2の方が簡単だけど、2の方があとあとのメンテナンスが楽になると思われる。

P.437 List A19-3
・doClockのif文の順序は逆。

■20章 Flyweightパターン

P.315 8行目
・次のようにnewをしてはいけません。というならば、コンストラクタを非公開にすればよいのではないか?
→共有したくない場合にはnewを呼びたいという場合があることを考えているのではないか? 問題20-1はそうだった。

P.320 4段落目インスタンスを明示的に削除することはできませんが。。。
・文章の方法以外にもsoft reference , weak reference , phantom reference なんかを使う方法がある。

P.322 問題20-2
・Runtime#gc()はガベージコレクションを強制的に呼ぶわけではない。リクエストするメソッド。Java の試験
にも良く出る。
・Flyweightを開発途中で導入する場合もあったりするので、newするよりはFactoryメソッドなどにしておくと、
後で楽な場合がある。
・最初からかなりのオブジェクトを共有できる可能性があるか、OptimizeIt等で性能測定してボトルネックと
なっている場合に適用すべきだろう。

P.322 問題20-3
・サーバ用途だと、lazy initializeするよりは、起動時に初期化したほうが早い場合が多い。
・クライアント用途だと、早く画面を出しておかないと、何度もアプリケーションを起動させられたりするから、
このようなlazy initializeは有効。

■21章 Proxy

P.326 List21-1 Printer.java
・デフォルトコンストラクタはなぜあるのか?
→問題21-1で使うため。
→そういうのが多い。結城パターンと命名。

■次回予定
27日くらいを予定しています。場所は未定です。
本はあと1章しかないので、次の本をやるか、もしくは、
この本に載っていないパターンについて議論するかといったか
まだ未定な状態ですが、今後MLで相談して決める予定です。
何か希望があれば是非MLに投げてください。

[ 戻る ]