こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の様子
第13章の応用問題
1
問題領域全体をパターンの観点から理解できる場合にのみ有効だという話があったので、必ず定義できる訳ではないという話になりました。
ただ、問題を定義するという表現がおそらく本書で初出なので、そもそも問題を定義と表現しているのがどういう意味なのかが怪しいという意見もありました。
そういった場合には共通性/可変性分析がおそらく使えるのであろうというのが本書の主張な気はしますが、ここに関してはこの後の章を見てみないと分からなさそうだということでした。
2
オブジェクトの生成というのが実装の具体的な手法の話なので、最年長のパターンだろうという話になりました。
3
Bridgeパターンは抽象的側面と実装を分けて考えるものであり、そこで実装を分けた後にAdapterパターンが出てくるので、先にBridgeパターンが来るのが自然ではないかという話になりました。
第13章あなたの意見
時間がなく、2に関しては話せませんでした。
1
一問に対して質問詰め込みすぎでは？笑という話がありました。
この規則が成立しないことはあるのですか？→しないことの証明が難しいという話はありますが、ここまでの例を見る限りはするんだろうという話になりました。
一気に詳細に立ち入るべき場合があるのか？→詳細というのがどのレベルなのかにもよりますが、要求仕様を洗い出しているタイミングでコードを書かなければいけないというレベルはまずなさそうだという話になりました。ただ、何もない状態で想像を活性化するために技術的調査することはあるかもしれないだろうという話になりました。
ラピッドプロトタイピングの示唆しているところか？→最初にラピッドプロトタイピングとはどのような解釈をするとよいか？という話になりました。価値があるかもわからないけれど作っているというイメージや、(製造業だと)試作品を作るときはコスト感を気にせずにとりあえず作るという話があるので、それに近い話が示唆されているのかな？という話になりました。そう考えると、いきなり詳細に立ち入ってそれをそのまま本番にリリースするといった場合はよくないよね、という話が出ました。(精度を上げていきながらやれるならOK)
モデリング大会
今回は自動改札機でモデリング大会をしました。以下、モデル図と話したことを記載します。
その1
- 駅のルートは物理的に変更されにくいから、Pay抽象概念がRouteに依存しても変更リスクほぼ0だからOKって感じになっているのが良い
- Routeがcalcfare()をしているが、ICcardかTicketかを知らないといけなくなる
- 値段の計算はRouteに入れないほうがよさそう
- Routeの値段を計算する別クラスを作ったほうがよさそう
- ICcardとTicketやCommuterPassの抽象化は、支払い方法が抽象化ポイントだと思って一括でやった
その2
- 運賃計算などのルールはもっと分けた方が良さそうだと思った
- 支払い方法で抽象化するのではなく、磁気と紙それぞれで抽象化している
- 要求仕様にあったAppleWatchは、磁気を継承して実装するのではなく集約で表現することにした
- Doorは赤外線監視などの役割がありそうなので別クラスにきった
その3
- チケット計算はTicket側で判断している。そこまで計算は難しくならなさそうという判断
- SuicaとかPasmoなどは作る会社によって仕様が全然違いそうなので、Adapterパターンを採用した
- Ticketは抽象クラスなのかInterfaceにすべきなのか怪しい
- 青春18切符とかを考えると、電子と紙それぞれで抽象化するほうがよさそう
次回の予定
次回のモデリング大会は自動改札機の実装をTypeScriptで実装してみるという話になりました。
ベースはその2のモデル図を使い、テストを書いてみながら変更に耐えられるかを確認してみようということになりました。
全体を通した感想
実際にみんなで考えてから議論すると、話の解像度が全然違うなあというのを強く感じました。
一度実装もしてみたいなあと思っていたので、次回のモデリング大会が楽しみです。
