オブジェクト設計スタイルガイド

より良いオブジェクト指向のコードを書くためのルールを紹介!
オブジェクト設計のベストプラクティスを適用することで、コードの読みやすさ、書きやすさ、メンテナンス性を向上させることができます。本書では、オブジェクトの種類に応じたオブジェクトの構築、メソッドの定義、状態の変更や公開など、設計ルールを説明します。Java、Python、C# など、あらゆるオブジェクト指向言語に適用できるテクニックを、擬似コードを使ってわかりやすく解説します。

クラスを書くたびに、コンストラクタで何をしてよいのか、状態を変えるメソッドは何を返すべきか、テストではスタブとモックのどちらを使うべきかで迷う人に向けて、その判断をルールの形にまとめた本が『オブジェクト設計スタイルガイド』 (Matthias Noback 著、田中 裕一 訳、オライリー・ジャパン、2023 年 7 月刊) です。原書は Object Design Style Guide です。版元の紹介文によれば、オブジェクトの種類に応じた構築、メソッドの定義、状態の変更や公開といった設計ルールを、Java や Python、C# などのオブジェクト指向言語に共通して使える技法として、擬似コードで説明しています。

全 11 章と早見表の構成、サービスとそれ以外のオブジェクト

1 章はクラスとオブジェクト、状態、振る舞い、依存関係、継承、ポリモフィズム、コンポジション、ユニットテストといった基礎の確認です。2 章ではオブジェクトを 2 種類に分け、サービスの作り方として、依存関係や設定値をコンストラクタ引数で渡す、すべての依存関係を明示する、コンストラクタではプロパティへの代入以外を行わないといったルールを並べます。3 章はサービス以外のオブジェクトの作成で、意味をなすデータだけを要求することや名前付きコンストラクタ、データ転送オブジェクトという例外を扱い、4 章はエンティティとバリューオブジェクトとデータ転送オブジェクトの性質、イミュータブルなオブジェクトを優先する理由、モディファイアメソッドの書き方を扱います。5 章のメソッド実装のテンプレートを挟み、6 章は情報を取得するクエリメソッド、7 章はタスクを実行するコマンドメソッド、8 章は書き込み用のライトモデルと読み取り用のリードモデルの分離、9 章は継承に頼らずに振る舞いを変える方法です。10 章ではコントローラやアプリケーションサービス、リポジトリ、イベントリスナといった役割ごとにオブジェクトを見渡し、11 章のエピローグでアーキテクチャパターン、テスト、ドメイン駆動設計への接続を示します。多くの章には練習問題と解答が付き、巻末にはサンプルコードのコーディング規約とスタイルガイド早見表の 2 つの付録があります。

ルールの形で設計判断を共有することの効き目

オブジェクト指向の設計原則は、抽象度の高い言葉で語られることが多く、目の前のクラスにどう適用するかは書き手の経験に委ねられがちです。本書の節題は「すべてのコンストラクタ引数を必須とする」「デフォルトでクラスを final とする」のように、そのままコードレビューの指摘として使える規則の文の形で書かれており、チームで判断を揃える道具になります。たとえば必要な依存をすべてコンストラクタで受け取る 依存性注入 を徹底すると、オブジェクトが何に依存しているかが引数の一覧だけで読み取れ、テストで差し替える箇所も明確になります。また、同一性で追跡する エンティティとバリューオブジェクトの区別 を意識し、値はイミュータブルにして変更の代わりに新しいコピーを返すと、どこで状態が変わったかを追う手間が大きく減ります。情報の取得と状態の変更を別のメソッドに分け、さらに読み取り用のモデルを書き込み用のモデルから切り離す考え方は、規模が大きくなると CQRS と呼ばれる構成にもつながっていきます。

前提知識と、類書との使い分け

前提として、何らかのオブジェクト指向言語でクラスを定義し、ユニットテストを書いた経験があると、各ルールがどんな不具合や読みにくさを防ぐためのものかを実感しやすくなります。コード例は擬似コードなので、特定の言語の文法やフレームワークの書き方を学びたい人には遠回りに感じられるかもしれません。変数名や式の書き方といった関数より小さな単位の読みやすさは『リーダブルコード』、業務の境界の切り方や戦略的な設計は『ドメイン駆動設計をはじめよう』のような本が受け持つ領域で、本書はその間にあるクラスとメソッドの単位の設計を扱う本と位置づけられます。設計の本をコード、モジュール、システムの段階で選び分けたい場合は 設計 / アーキテクチャ本の選び方 が参考になります。

クラス設計の判断がレビューのたびに人によって揺れているチーム、テストが書きにくいコードの原因を構造から直したい人、設計原則の名前は知っていても日々のコードに落とし込めていない人にとって、本書は判断の基準をルールとして手元に置ける一冊です。付録の早見表をレビューの観点表として使えば、読んだ内容をすぐにチームの習慣へ移せます。