リファクタリング時のコツ的な側面と、ドメイン駆動設計を噛み砕いて記載してある側面があるのでこちらの本を読んでまとめ
前半
小さくまとめて分かりやすくする
変更が大変なプログラムの特徴を押さえる
- メソッドが長い
- クラスが大きい
- 引数が多い
プログラムの変更が楽になる書き方
- メソッド内の例
- 分かりやすい名前を使う
- 長いメソッドを段落毎に行間を開けてみる
- 目的毎に変数を用意する
- メソッドとして独立させる
ドメインオブジェクトである事を意識する
- 業務用語に対応する対象領域をドメインと呼び、そのクラスをドメインオブジェクトと呼ぶ。ドメインへの理解に努力することで、プログラミングと一致させられ、変更が楽で安全になる
小さなクラスで分かりやすく安全にする
- データとロジックを概念的に切り分けて認識した上で、それらを分かり易く整理して組み合わせる
- 基本的なデータの種類を押さえる
- 判断
- 加工
- 計算
値用のクラスを作る
- 俗にいうイミュータブルオブジェクト
- 値オブジェクト(Value Object)
- setterを作らない
- 値を重複させない
配列やコレクションはロジックを専用クラスに閉じ込める
- 複雑なので複数のことを1配列やコレクション処理の中でやらせない
- コレクション操作のロジックをコレクションクラスに移動する
- 同じ型のコレクションオブジェクトで返す
- イミュータブルにして外部に渡す
場合分けのロジックを整理する
以下のオブジェクト指向設計の基本方針から外れない
- コードのかたまりは、メソッドとして抽出して独立させる
- 関連するデータとロジックは、1つのクラスにまとめる
ifやswitchの使い方に注意する
- 区分ごとのロジックはプログラムを複雑にするのでそのまま書かない
- elseをなくす
- 早期リターンやガード節を使う
列挙型を活用する
- つまり多態を使う(enumはシンプルに記述できる)
- 区分ごとの業務ロジックをわかりやすく整理できる
- 区分ごとに別のクラスに分けると独立性を高めることができる
- 状態遷移などの管理に有効
ドメインモデルの考え方で設計する
ロジックとデータを持つクラスを一緒にする
- つまりドメインクラスにする
- 1メソッド1ロジックの置き場と考える(値だけそのまま返す処理にしない)
- 書きながら設計を見直す
- 短くして移動をし易くする
- メソッドは必ずインスタンス変数を使う
業務を俯瞰する
- パッケージなどを用いてクラスを整理する
- 3層(プレゼンテーション・アプリケーション・データソース) + ドメインモデルで考える
アプリケーション機能を組み立てる
業務の関心事を分類する
- 3分類する
- ヒト
- モノ
- コト
- 関係性を把握する
- コトは背景の業務ルールなどが前提となっているので重要
業務ルールを記述するドメインオブジェクトの基本パターン
| ドメインオブジェクト | 設計パターン |
|---|---|
| 値オブジェクト | 数値、日付、文字列をラッピングしてロジックを整理 |
| コレクションオブジェクト | 配列やコレクションをラッピングしてロジックを整理 |
| 区分オブジェクト | 区分の定義と区分ごとのロジックを整理 |
| 列挙型の集合操作 | 状態遷移ルールなどを列挙型の集合として整理 |
書籍情報
増田 亨, 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
https://amzn.to/2FkD62f
雑感
文献元を読んでからだと理解の度合いがまた違う