[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 12330] 第 5 回議事録

皆様お待たせしました、第5回議事録ポストします。


Java読書会第5回 議事録
出席者
高橋(徹)　金井　岩室　岩永　小棚木　奥　石黒　高橋(智)　中島　遠藤　岩永
村山　根本(記)

第Ⅶ部より
第17章　Decoratorパターン
■図17.4 のConcreteDecoratorA ConcreteDecoratorBの名前が
　図17.3と合っていないないのでわかりにくい。

■例17.1 CallTrailerを呼ぶタイミングで印刷順序を決めているが
　オブジェクトのLinkListをFactoryで管理して決めるべきなのか、責務の所在が
　不明瞭。ラインプリンターへの印刷のイメージだからこうなってしまう。
　本来ならレイアウトマネージャーがいて、配置管理すべきところである。
　でないとヘッダーやフッターは良いが、サイドバーの印刷などができない。
　ストリーム処理の概念で考えることとしないと、訳が分からなくなる。

■アスペクトのbefore/after/adviceを一つのmethodに複数付けた時は、順序に問題が起きる。
　AspectJは adviceの順序関係が定義可能になっている。
■adpectJ以外のアスペクト指向にはJavaAssistがある
■aspectjのデバッグはほとんど不可能では?
　bytecodeへの動的組み込みのタイプの場合、デバックはムリかもしれない。
　
■Frameworkを先に作ってシステムを作るのは失敗しやすい、ビジネス目的がはっきりしないと
　Ajax+Strutsの組み合わせのように、正体不明な組み合わせなケースに成りやすい。 
■Decoratorの例として、WindowManager はFrameworkとしてDecorator的な
　動きをしているかもしれない
■preparedStatementはcloseしてもcacheに残っているが、
　これはJ2EE Serverがcacheしてくれる為。
　connectionのみのcloseで全部解放されるようなことはない。
■Fileの操作は、CからJavaに移ったときに、最初にイヤになってしまうコーディングの例、
　findInputStreamなど、やることが多い。
■欄外「この構造がパターンなのではない」の意味は、前後に機能を追加するのがPattern
　なのではない、という意味である。
■Decoratorの本質は連鎖構造ではない。連鎖の隠蔽にある。
　それ以外の定義は、オレ流Decoratorになるのかどうか不明
■DecoratorにMethod追加したら飾り付け以上になってしまうのではないのて、
　適切でないかもしれない。
　
第18章　Observerパターン

■Observerパターンの適応ケースとして、1対多のケースが事前に
　特定されていなくてはならない。
■Subjectの型自体には変更が発生しないことが予測されていなくてはならない。
　update()の巡回中にひとつでもexceptionが出たらどうするのか決める必要がある。 
　notify()の巡回中は、そのiterationはコピーを作って、処理が廻るので、
　対象objectの追加/削除には対応可能。

表18.1
■第4の分類方法の、構造の疎結合は第4の、と言うのにはムリがある、視点が違う。

第19章　Template Methodパターン
■サンプルとしてDBのCONNECTコマンドの例はTemplate Methodのケースとしては
　不適切ではないのか? 実資源名の仮想化が適切例とは思えない。
■図19.5 新機能追加というよりは新要求追加と言うべき、method数は増えていない、 
　内部の処理が増加している。
■図19.5 BaseClassにconcreteMethodがあるが、どうやって抽出しているのか、不明。 
　本来ボトムアップで使うべきパターンであって、設計段階でTemplate methodを
　採択する局面が見えない。

19.8練習問題
■特殊な呼び出しとは?  Vertual Methodのことを言っている
　自分で書いていないmethodが呼び出し可能になっている点が特殊と言える。
■Template method は小さなフレームワークとも言える、
　hollywood principleの小さい実施例と言える。

■if文がなくせる点がTemplate methodのいいところ。処理が速くなる。テストもしやすい。
　I18N化も、このタイプ
■Template methodはStrategyとは異なって、アルゴリズム自体は固定
　Strategyのように、動的には切り替わらない。

第Ⅶ部
第20章　生成に関するパターンから得られる教訓
■ファクトリとは、つまり作る人と、使う人を役割分担すること。
■使う人はnewしてはいけない、常にgetで呼び出すべき
　つまり、Factoryとは、IDLが開発する、とも言える。

次回は、第21章 SingletonパターンとDouble-Checked Lockingパターンより
お勧め予習記事
http://www-06.ibm.com/jp/developerworks/java/020726/j_j-dcl.html


以上..