こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
オブジェクト指向のこころを毎週1章ずつ読んでいくイベントです。今日は第2章でした。
会の様子
20:00-21:00は該当章を読み、21:00-は読んだ章の感想戦をしていくグループと練習問題を解いていくグループに分かれました。
自分は練習問題を解いていくグループで参加していきました。
1章の練習問題の回答
練習問題は、第1章がまだ残っていたということだったので途中から(応用問題の4から)やっていきました。なお、基礎問題は本に書いてある内容を覚えているかのチェックに近いので、参加者の皆で解くのはやめています。
以下、問題ごとに回答+議論した内容を記載します。
応用問題4
回答
オブジェクトを使う側/使われる側があったとき、使われる側にインターフェースを適用することで、使われる側の詳細に関してオブジェクトを使う側が知る必要がなくなり、変更に強くなる。
議論した内容
インターフェースを切る具体的な例も答えてほしい意図なのかな？という話が出ていました。
応用問題5
回答
()内は、本には書かれていないけれどおそらく必要になってくるであろう責任
- 教室...自らの場所を把握する、(収容可能人数を把握する)
- 学生...今いる教室を把握する、次の教室までの移動する、(セミナーを受講する)
- 先生...次の教室に移動することを命じる
- 情報提供者...次の教室までの移動方法を教える
議論した内容
題材が抽象的なので、もっと責任を出そうと思えば出せそうだけれど、本に書いてある内容で区切るとこれくらいかな、という話が出ていました。
あなたの意見1
回答
実際に作った後に、実現したかった要求が誤りだと気がついた
議論した内容
事業戦略レベルで要求の変更があるときは、ここに書いているような話はあまり使えなそうだけれども、レイヤーを分けたり要求分析をすることで変更が起きやすそうな戦略は一定はわかるのではないか？という話をしていきました。
あなたの意見2
回答
規模が小さいものでなければ同意できる。機能分解を用いて構造化プログラミングを行うと、プログラムが階層構造になり、一番上の階層のプログラムはすべてを把握する必要が出てくる。
議論した内容
最初は規模の話が出てこなかったのですが、規模が小さいプロトタイプのようなものであれば機能分解でも全然問題ないよねという話が出ていました。
また、長期間メンテナンスをすることを想定してないようなプログラムだったりは変更回数が少ないので、そういった場合は機能分解して作ってもいいかもしれないという話も出ていました。
あなたの意見3
回答
- 要求には変更が起こる前提で開発をする
- 要求分析ツリーを作成し、レイヤーごとに論点を整理している。その上で変更が起きやすいレイヤーと起きにくいレイヤーを特定する。
議論した内容
開発の基本スタンスとしては、要求には変更が起こる前提で開発をするのが良いという一方で、質の高い要求を引き出すための工夫も必要だよねという話をしていきました。
具体的には、上に書いた要求ツリーの話だったり、実例マッピングなどを活用してテスト可能な状態に要求を落とす&曖昧な要求を探して必要に応じて明確化するといったテクニックがあるよねという議論が出ていました。
2章の練習問題の回答
続いて、2章の練習問題の回答をしていきました。こちらも基礎は飛ばしています。
応用問題1
回答
本に書いてある条件を満たすような形で例を挙げるなら猫と動物、猫と動物園。ただし、色々批判がされている例である。
議論した内容
猫と動物をis-aとすることに対する批判はどこからスタートしているのだろうか？という話をしていきました。
批判自体はそこそこ出てくるのですが、批判の原点はよくわからず、時間を使いすぎてもあれなので暇があったときの宿題になりました。
応用問題2
回答
13派...単純に、13この矢印が記載されているため
3派...手順と呼べるのはMainからShapeDBに対して伸びている矢印のみなので、3
議論した内容
そもそも「手順」に関する定義が本書に出てきていない気がするので、そこから議論がスタートしました。結局「手順」がなんなのかは分からなかったのですが、話の流れから、本書のシーケンス図の粒度はめちゃくちゃなのでは？という話になりました。
1-13を並列にして比べるとたしかにぐちゃぐちゃで、一つのシーケンス図として読みにくいという意見があった一方で、本書の定義に従えばシーケンス図はオブジェクト同士のふるまいを表現する相互作用図的な意味合いが強いので、オブジェクトの粒度が適切であると仮定すれば、シーケンス内の処理に関する記載粒度が変わるのはそこまで違和感がないという意見も出ていました。
あなたの意見
回答
上記の応用問題の流れで突入したこともあり、明確な回答をだすというよりは議論の延長線上で色々話している感じでした。
議論した内容
最初に処理の粒度をはかる具体例として、「AWS S3にオブジェクト置く」は適切なのか？という話が出ました。
オブジェクトが「データ保管庫」くらいの粒度でしか表現されていない場合は、やや詳細すぎる気がする一方で、クラス名の候補が決まっていたり「AWS S3」といったオブジェクトが登場しているなら、適切な粒度なのでは？という話が出ていました。
その後はやや脱線して、シーケンス図を使いたいシチュエーション(実際の現場で使っているシチュエーション)に関して話をしていきました。
シーケンス図はプログラマー同士の会話で使っているという意見や、アーキテクトが事業戦略を表現する際に使っているという意見が出ていたのですが、後者のような使い方をしている場合、シーケンス図の前に概念モデリングなどを挟んでいないと、オブジェクトの粒度がめちゃくちゃなシーケンス図ができあがる可能性があるため、危険だよねという話が出ていました。
話の流れから、本書に出てきたクラス図はどう使うの？という話になり、正直そこまで使っていない気がするが以下のような状況では使っているかも...?という話がありました。
- 保守用のドキュメントとして求められる場合
- ドメインエキスパートやビジネスサイドと会話する場合(この場合、Miroやホワイトボードなどでクラス図よりももっとラフな図で会話するという意見もありました)
- クラス図を作っているツール会社に所属している場合
全体を通した感想
時間を延長するくらい議論が盛り上がり、様々な話ができてよかったです。
本の特性上、実際に現場で実践されている方同士で議論できるのがよく、せっかくなので具体的なコードを書きながら(モブプロしながら)理解をより深いものにしていきたいなあと思いました。(次回以降どこかのイベントで機会を作れそう？)
