第3回「オブジェクト指向のこころ」読書会に参加しました

第3回「オブジェクト指向のこころ」読書会（2024/01/31）に参加しました！

オブジェクト指向のこころを読む会 Vol.3

今回は第三章、第四章を読み、「応用問題」と「あなたの意見」について参加した方々と回答の共有と意見交換を行いました。

第三章

第三章では、題材としている問題領域についての説明が主に行われていました。

応用問題

Q.CAD/CAMの事例が抱える本質的な問題とはなんでしょうか

話の中で出てきた回答

CAD/CAMシステムの後方互換性のないバージョンアップが頻繁に発生し、変更に工数のかかるエキスパートシステムがそのCAD/CAMシステムに直接依存している状態が発生するのはよくないという問題

Q. ポリモーフィズムは、ジオメトリーの抽出レベルで必要となりますが、フィーチャーレベルでは必要となりません。その理由はなんでしょうか。

話の中で出てきた回答

「ジオメトリ抽出を行う」というレベルでCAD/CAMシステムのバージョン変更によってエキスパートシステムの変更を余儀なくされるのは好ましくない。そのためポリモーフィズムをジオメトリ抽出レベルでは担保する必要がある。
しかし、フィーチャーレベルにおいては、各フィーチャーの特徴や持つべきメソッドが異なることは自明なため、各フィーチャーの実装クラスの使用方法は異なっても問題がない。（＝各フィーチャークラスがポリモーフィズムを満たしている必要はない）
逆に異なる特徴を持つ各フィーチャーを無理やり抽象化してしまう方が危険なのでは？

あなたの意見

Q. 私はCAD/CAMの問題における用語定義に時間と紙面を割きました。この作業についてはどう思いますか？

話の中で出てきた回答

ユビキタス言語の話だ！！
今回のCAD/CAMシステムのような複雑な問題を理解するために用語について合意を取るのは理解を助けるために重要。実際に用語表に何度も戻りながら本を読み進めた。
でもちゃんとユビキタス言語を遵守して開発するのって難しいですよね。どうしても形骸化してしまうような経験がある。
表で管理する以外のいい方法などはあるのでしょうか。

第四章

第四章では、第三章で説明されていた問題について、実際にオブジェクト指向で解決するという話でした。

応用問題

本章で解説したCAD/CAMの問題を解決するためのアプローチを解説してください。また、このアプローチは妥当なものですか？

話の中で出てきた回答

今回は三章で挙げられていた「エキスパートシステムがCAD/CAMシステムを使用する際に、エキスパートシステムが複数バージョン存在するCAD/CAMシステムのバージョンの差異に影響を受けてしまう」という問題を解決するために、複数バージョンのCAD/CAMシステムを包括するような抽象クラスを作り、エキスパートシステムからバージョンの差異を意識しなくても良いようにしたというアプローチをとった。
今回の解決策だと問題があることが本には書かれていたが、このアプローチ自体は正しいアプローチだと思う。私もこのようなことをすると思う。
これ以外にどのような方法があるのか？

あなたの意見

詳細に踏み込むことをできるだけ遅らせてください。あなたはこれに同意しますか？同意する、しないに関わらず、その理由はなんですか？

話の中で出てきた回答

詳細について話し始めると戻るのも難しくなる。抽象的な部分である程度成熟させてから進んだ方が良かった経験が多い。
基本的に未来の自分の方が優秀（ドメインについての理解が深まっている）なので、初めから詳細に詰めて戻れなくなるのはリスキーですよね
「詳細に踏み込まない」というのが「概念レベルで詰めきらないと実装に移らない」という意味だとすると、ちょっと賛成できないかもしれない。実際に概念をモデリングする際にコーディングを行いながらトライアルアンドエラーをしてみると、紙の上では気づけなかったことに気づくことが多い。
コーディングしながら、実際にクラスを設計してみるというのはとてもわかる。ではコーディングの初期段階で「詳細に入りすぎてるな」と思うポイントはどこか？
- 処理のアルゴリズムなどについて考え始めるのはかなり詳細かもしれない。実際に試行錯誤フェーズではメソッドのシグネチャと仮の戻り値とかだけ決めて設計している感じ
- DBのテーブルの型とかについて話し始めるとちょっと詳細かもと思うかもしれない。
- 確かに、「モデリング→ある程度モデルが固まる→どう保存するか考える」みたいな流れにできると理想かもしれないですね。

「優れた解決策であると直感的に感じられなかった」という理由で、ある解決策を破棄しました。アナリストやプログラマは直感に従うべきでしょうか。

話の中で出てきた回答

これは難しい問題ですよね。。。時間が無限にあるなら、「なんかしっくりこない」でひっくり返したいところっていっぱいあります。
チームで開発していて、「ちょっとしっくりきていない」という理由である程度できているモデルを最初から考え直すとかって踏み切れないですよね。
逆の立場で考えると、「なんか違う」でモデリングしていたものがひっくり返されてしまうのは賛同できないかもしれないですね。でも「なんか違う」というのは大切なメッセージだと思うので、「なんか違う」を深堀して、違和感の原因を引き出そうと試みると思います。
ドメインに明るい人が「なんか違うかも」って言ってたら絶対聞いた方がいい気がしますね
逆に、自分が「なんか違う」と思っている時に、チームに違和感があることを伝えることは大切かもしれないですね。もしかしたら他の人で違和感を感じている人もいるかもしれないですし、それがモデリングの重大な問題を孕んでるかもしれない。

感想

普段の業務の話と本の内容を絡めて皆さんとお話しできたのがとても楽しかったです！

変化しにくい（させたくない）ものと、変化してしまうもの。この両方を繋ぎ止めるために頭使ってモデルを考えているのがとても面白かった。次回以降、デザインパターンの話に入っていくのでとても楽しみです！

次回について

次回は5章について行うみたいです！