こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
今回からしばらくは、タイトル通りオブジェクト指向のこころを読む会になっています(???)
16章 応用問題1
本書で触れられている概念・仕様・実装の3レベルであれば、概念レベルの話に一番近そうだという話が出ていました。
本書では具体的に使うパターン名まで分析マトリクスの中で踏み込まれていますが、これはあくまでも概念を洗い出した上で次のステップとして行っていることなので、分析マトリクス自体は概念を生み出すものだろうという話になりました。
また、分析マトリクスという形で使用したわけではないけれど、コードを書く前にテスト設計する際に使うテーブルとして利用しているという話も出ていました。
16章 応用問題2
行が共通性を表しているのは間違いなさそうだけれども、列は共通性を表しているのか？という話がありました。(本書で言えばアメリカ共通のルールとも言えそうだし、アメリカやカナダという可変性を洗い出しているとも言えそうで、共通性/可変性どちらとも言えそう)
ただし、共通性/可変性分析と分析マトリクスは必ずしも1:1対応するようなものではないので、流動的要素を洗い出したいという目的は一緒であれど、使い方が違ってきそうだという意見も出ていました。(似ているし1:1対応できる場合もあるが、概念を共通性/可変性分析で洗い出して、具体的な振る舞いを分析マトリクスで洗い出す)
また、システムを実際に設計する際には、最初に共通性/可変性分析で洗い出した後、具体的な行動レベルの振る舞いは分析マトリクスで整理するみたいな形になるんだろうなあという話をしました。
割り勘モデリングや自動販売機で分析マトリクスは使えるのか？
脱線して、本書の例であれば適用できるのは良いとして、例えばモデリングのお題として出がちな割り勘や自動販売機に関しては分析マトリクスを使えるのだろうか？という話が出て、みんなで分析マトリクスを試しに書いてみました。
実際に書いてみながら理解を深めていったところ、以下のような点が使う上で重要そうだという話になりました。
- 行には振る舞いを書くようにしたほうがいい
- まずは概念から洗い出した方がよい
- いきなり分析マトリクスを書くことは業務ではまずなさそう
- 抽象度が異なるときは、分析マトリクスをネストさせるような形で使うと概念が整理できる
17章 応用問題1
新たな機能を付加するオブジェクトの実装方法と特殊ケース毎におけるオブジェクトの体系化方法を分解しているという話をしました。
また、Decoratorパターンのkey Pointとして、追加機能群が規則に従っているかどうかわからないような状況で使うのが重要なんだろうねという話や、関数型言語だとDecoratorパターンみたいなことは自然にできそうだという話が出ていました。
全体を通した感想
1時間半以上やっていたことを考えると驚くほど進んでいないのですが笑、分析マトリクスを実際に使ってみて、本には書かれていないけれど業務で使うときは注意したほうが良さそうなコツのようなものを会得できたのはすごく大きな収穫でした。
ばんばん章を消化していきたい気持ちもありますが、一個一個の概念を脱線しながらも丁寧に学んでいくスタイルもめちゃくちゃいいなあと思いました。
