読書メモ。2025年62冊目。
『オブジェクト設計スタイルガイド』を読んでの感想となります。（2025/9/4記載）
本の概要
オブジェクト設計において、コードの読みやすさ、書きやすさ、メンテナンス性を向上させるにはどうすればよいでしょうか？ 本書は、より良いオブジェクト指向のコードを書くためのルールを紹介します。オブジェクトの種類に応じたオブジェクトの構築、メソッドの定義、状態の変更や公開など、設計ルールを説明します。Java、Python、C#など、あらゆるオブジェクト指向言語に適用できるテクニックを、擬似コードを使ってわかりやすく解説します。コードの品質を上げるためのルールを紹介する本書は、プログラマ必携の一冊です。
引用：
動機
- チーム開発でコード品質に対する共通認識を揃える重要性を感じている。
- 直近でPydanticを導入したため効果的に活用したいと思っている。zenn.dev
- プログラミングするパンダさんがご紹介されていたことでいつか読みたいと思っていました。
本書からの学び
本書は今まで理解していたオブジェクト指向を実現するための知識を構造化して整理し直すために、とても有効に感じました。
特に具体的で詳細な整理と、それに対応した丁寧なサンプルコードに、理論だけでなくソースコードレベルでの物理的な理解も進めることができました。
逆に、初学者にとってはもう少し俯瞰した整理から具体的な内容に落とし込んで理解を進めた方が吸収しやすいかもとは思いました。
抽象レベルでオブジェクト設計を理解した上で、本書にあたると理解がしやすいイメージがあります。
一方で、一回だけの通読だと理解しづらい部分は落ちていく気もするため、本書をいつでも取り出せるように手元に置いておくか、Linterのように意識せざるを得ない機構を作りたいと思いました。
いずれにせよ、常に変更を求められる要求にプロダクトが柔軟に対応できる構造を実現するために、本書を土台にチームでコード品質に対する知見を揃えたいと思いました。
また、私が扱うプロダクトの言語がPythonであることから、本書に書かれている内容をどのように適用していくかも考えていく必要があると思っています。
開発メンバーからの学び
中堅メンバーからの学び
特に、継承とコンポジションに対する説明は、今までいろいろな書籍から知ってはいたものの、本書の説明から解像度を上げることができたとのことでした。
具体のレベルでチームの認識を揃えることで、より実践に対する方向性を合わせやすいのではというコメントが興味深かったです。
今までのチームの傾向的にも、抽象度が高いレベルでの議論で空中戦になりやすかったため、メンバーそれぞれのコンテキストに依存しないすりあわせのためのガイドラインとして期待できそうです。
若手メンバーからの学び
これから定期的に学んだことをチーム内ですりあわせする機会を作ってくれたため、
チームとしての学習も進みそうです。
忘れたくないメモ
本書で特に印象に残ったポイントを振り返ります。
ユビキタス言語
ドメインエキスパートと「販売注文」の概念について話し合うとき、彼らは販売注文を「構築する(construct)」とは言わないでしょう。もしかすると、彼らは販売注文を「作成する(create)」 とは言うかもしれませんし、販売注文を「出す(place)」といった、より具体的な用語を使うかもしれません。このような単語を探し、名前付きコンストラクタのメソッド名として使用しましょう。
コンストラクタの名前に限らず、使われ方を意識して設計したい。
可変性を限定する
イミュータブルな値として実装されたオブジェクトにも当てはまります。もはや共有しているという感覚はなくなります。また、異なるオブジェクトが必要な場合は、オブジェクトを修正するのではなく、新しいオブジェクトを作成します。つまり、イミュータブルオブジェクトが変数やプロパティの中にあって、それについて何かを変更したい場合は、新しいオブジェクトを作成して変数やプロパティに格納するのです。
イミュータブルにすることで、変数に対する前後の文脈を意識しないで済むようになる。
将来の認知負荷を下げることができる。
カスタム例外クラス
はじめて知った考え方でした。名前付きコンストラクタを使用すると、クライアント側のコードが非常にすっきりします。例外クラスの名前とコンストラクタのメソッドの名前を組み合わせると 「ID...のプロダクトを見つけることができませんでした (Could not find product for ID...)」と文章のように読むことができます。メッセージは、呼び出し元ではなく例外クラスの内部で組み立てられます。
名前で例外を限定することで、対処時のキャッチアップも速くなるイメージを持ちました。
ライトモデルとリードモデル
クライアントの中には、エンティティをライトモデルとして使用しても、そこから何らかの情報も取得する必要があるものがあります。こういったクライアントは意思決定をしたり、特別な検証のためにこの情報を必要とします。このような場合にクエリメソッドを追加してはいけないと思う必要はありません。クエリメソッドは決して禁止されているわけではありません。本章のポイントは、情報を取得するためだけにエンティティを使用するクライアントは、ライトモデルではなく、専用のリードモデルを使用すべきだということです。
本書のどの項目も今まで行ってきたプログラミングに型／構造を与えてくれるから取り扱いやすくなります。
そのうえで、こうした原則第一ではない説明も分かりやすい。
追記
著者動画
NotebookLMで解説してもらいました。興味深かったです。
いろいろYoutubeに登壇動画がアップロードされているので、参考にしたいです。
構造についての整理
本書に記載のオブジェクトの構造について、実態と名称の記憶が難しく、自分の理解度を上げるために整理しました。
