[戻る]
Java読書会BOF「Practical Design Patterns for Java Developers」を読む会 第5回¶
場所 |
|
出席者（敬称略） |
高橋（智）、高橋（徹） |
本日は、p.150「5章 Behavioral Design Patterns」の途中、p.150 Checking all the elements with the iterator patternから
Part 2: Implementing Design Patterns Using Java Programming¶
第5章 振る舞いに関する設計パターン¶
本章のサンプルコードは github から入手可能
イテレータパターンですべての要素をチェックする¶
誤植 p.151 例5.8のキャプションが、例5.6と全く同一（コピーしたまま修正漏れと思われる）
誤植 p.152 例5.9のキャプションが、例5.10と全く同一（コピーしたまま修正漏れと思われる）
誤植 図5-5のUML図は誤り含む
StandardVehicleからVehicleの関連は、・・・▷
VechiclePartsIteratorからPartsIteratorへの関連は ・・・▷
情報交換にメディエーターパターンを利用する¶
メディエーターパターンのUML図は、通信の送り手（Sensor）だけが登場し、通信の受け手が存在しないので一見分かりにくいです。
メメントパターンで希望の状態に戻す¶
p.156 例5.12 var型のローカル変数定義で右辺がメソッド呼び出し式だと型が分からないのでコード理解が難しい
nullオプbジェクトパターンによるnullポインター例外状態の回避¶
オブザーバーパターンを使用して全ての関係者に情報を提供し続ける¶
誤植? p.160 Producer Customer patternは、Producer Consumer patternの誤記では？
p.162 図5.9のUML
SystemObserverはabstract classなので、CockpitObserverとEngineObserverとの関連は、実線の-▷となるはず。
パイプラインパターンを使用したインスタンスステージの処理¶
p.164 図5.10 のUML
ElementとSystemElementとの関連は実装の線（点線の▷）
ラムダ式でElementの数珠繋ぎを実現しており、非常に理解が難しい。UML見ても分からない。
シーケンス図を書くと理解できるか？
ステートパターンによるオブジェクトの動作の変更¶
p.166 誤植 図5.11 UML図
VehicleStateインタフェースを実装するStopState/InitState/StartStateとの関連は、点線の▷が正しい
戦略パターンを使用してオブジェクトの動作を変更する¶
p.169 誤植 図5.12 UML
TransportStrategyインタフェースを実装するBusStrategy/CarStrategy/TruckStrategyとの関連は、点線の▷が正しい
VehicleSensorクラスにstopMeasure()が2つ重複している
テンプレートパターンによるプロセスの標準化¶
VehicleSensorはabstract classなので、BreakSensorとEngineSenserとの関連は、実線の-▷となるはず。
ビジターパターンを使用したオブジェクトタイプに基づいたコードの実行¶
p.174 誤植 図5.14 UML
SystemCheckインタフェースを実装するBreakCHeck/EngineCheck/VehicleCheckとの関連は、点線の▷が正しい
SuspensionCheckからSystemCheckへの関連が抜けている（点線の▷）
CheckVisitorインタフェースを実装するVehicleSystemCheckVisitorとの関連は、点線の▷が正しい
SystemCheckインタフェースからCheckVisitorインタフェースへ型の使用（点線矢印）の関連が必要
まとめ¶
質問¶
標準的なVisitorパターンでリスコフ置換原則が破られる
型を知らなくてもコレクション内要素をたどるのに役立つイテレータ〜パターン
実行時にインスタンスの動作を変更できるストラテジーパターン
ランタイムが未定義の状態を透過的に識別するNullオブジェクトパターン
Java Stream APIで最もよく使われるストラテジーパターン
実行時にすべてのクラスタ化されたクライアントに通知する：オブザーバーパターン
コールバックの実装には：ビジターパターン、（オブザーバーパターンも含めるか？）
Part 3: Other Essential Patterns and Anti-Patterns¶
第6章 同時実行(Concurrency)設計パターン¶
メソッド実行とアクティブオブジェクトパターンの分離¶
p.183 図6.2 UML
ThreadからRunnble<V>への関連は、implementsの関連（点線の▷）
SportVehicleからMovingVehicleへの関連は、継承の関連（実線の▷）
非同期メソッド呼び出しパターンを使用したノンブロッキングタスク¶
p.187 図6.4 UML
全体で、インタフェース型から具象型への関連は implementsの関連（点線の▷）
p.187 下10l "it is not causing by delas." のdelasとは何か？ 英語ではない単語。
前のタスクがボーキングパターンで完了するまで実行を遅らせます¶
図6.5の絵は、Java Mission Contrlの図と同じ。色の意味は？
図6.6のUML
Runnableインタフェースを継承するExecutorServiceインタフェースの関連は、継承なので実線の▷
二重チェックされたロックパターンを備えた一意のオブジェクトインスタンスを提供する¶
p.191 下7l 「追加のトレッドモデル（tread model）」はスレッドモデル（thread model）の誤記
p.192 例6.8の下、（図5.5）とあるが、（図6.7）の誤記
p.192 図6.7 この図を見ても、よく分からない。
コードのamountが５なのに10個実行しようとしているので、意味が少し不明
宿題）JMCでスレッドの動作を見てみる
p.194 図6.8 UML
interfaceの実装の関連が実線ではなく点線になるはず
読み取り/書き込みロックパターンによる意図的なスレッドブロックの使用¶
p.197 図6.10 UML
interfaceの実装の関連は実線の▷であるべき
SensorWriterクラスの属性 readLock:lockは、sensor:Sensorの誤記
SensorWriterクラスの操作 writeSensorValue()は実装に存在せず、誤記
Sensorクラスの操作 setValue(v)はwriteValue(v)の誤記
java.util.concurrent.Exchanger の例について、参考記事
プロデューサー/コンシューマーパターンによる実行ロジックの分離¶
本日は、p.201 スケジューラパターンを使用した分離タスクの実行の前まで 次回は、p.201 スケジューラパターンを使用した分離タスクの実行から
[戻る]