# 現場で役立つシステム設計の読み方整理

###### tags: ペチオブ

## Chapter1 小さくまとめてわかりやすくする

### なぜソフトウェアの変更は大変なのか
- ソフトウェアの変更に立ち向かう
変更容易性が低いのは「設計」に問題があるという前提
変更容易性が低い -> どこに何が書いてあるかわからない、思わぬ副作用、修正箇所が広がる
設計とは -> ソフトウェア全体をすっきりした形に整えること。
-> どこに何がかいてあるかわかりやすくする。
- 変更が大変なプログラムの特徴
- メソッドが長い
- クラスが大きい
- 引数が多い

- 変更するたびに変更が大変になる
なぜ適切でないコードが生まれるのか
「ちょっとした」コードの追加の繰り返し

### プログラムの変更が楽になる書き方
- わかりやすい名前を使う
動くだけと、理解できるとでは意味が違う
対象ととする分野で普通に使われている言葉を使う -> ユビキタス言語

- 長いメソッドは「段落」に分けて読みやすくする
空行、インデント -> 視覚からの理解

- 目的ごとに変数を用意する
破壊的代入
ローカル変数を概念ごとに用意し、行間も疎結合に。

- メソッドとして独立させる
上記の視覚からの理解をさらに進め、構造からの理解へ昇華させている
スコープが限定される事により影響範囲の局所化
- 局所化
- 再利用性
- メソッド名による理解のしやすさ

- 異なるクラスの重複したコードをなくす
責務毎のクラスへのリファクタリングの手順

- 狭い関心事に特化したクラスにする
上記と合わせて単一責務原則の説明に近い

業務で使われている用語に合わせて、その用語の関心事に対応するクラスを**ドメインオブジェクト**と呼ぶ

- メソッドは短く、クラスは小さく

### 小さなクラスでわかりやすく安全に
- データとロジック
基本的な型は3つ
- 数値
- 日付
- 文字列

- 基本データ型の落とし穴
- 値の範囲を制限してプログラムをわかりやすく安全にする
単一責務なクラスをさらに独自の型でより業務を反映したクラスとして作成する方法の解説

- 「値」を扱うための専用のクラスを作る
Value Object
値オブジェクトは業務の用語そのものです。

- 値オブジェクトは「不変」にする
完全コンストラクタ

- 「型」を使ってコードをわかりやすく安全にする
同じ数値型でも意味が違えば専用のクラスを用いる。

### 複雑さを閉じ込める
- 配列やコレクションはコードを複雑にする
コレクションに対する問題提起

- コレクション型を扱うコードの整理
基本的に先述の値オブジェクトと同じ考え方を取り入れる。
-> データとロジックを一つのクラスに集約する
-> Listを一種類のみもつ専用のコレクションクラス
-> ファーストクラスコレクション
- コレクション型を扱うロジックを専用クラスに閉じ込める
ファーストクラスコレクションの説明

- コレクションオブジェクトを安定させる
- コレクションオブジェクトは業務の関心事
### まとめ
- オブジェクト指向設計は変更を楽で安全にする工夫
- コードの整理の基本は名前と段落
- 短いメソッド、小さなクラスを使ってコードを整理する
- 値オブジェクトでわかりやすく安全にする
- コレクションオブジェクトで、複雑なロジックを集約して整理する
- クラス名やメソッド名と業務の用語が一致するほど、プログラムの意図がわかりやすくなり、変更が楽になる

### 動画的な解説ポイントmemo

- クラスの単位の話し
- 最初に問題提起をし、残りはその解法といった構成
なぜソフトウェアの変更は大変なのか -> 問題提起

どんなコードが変更し辛い？
1. 大きさが適切ではない

どのように解決する？

意味がある名前を付ける事でコードが説明を始める
**プログラムが業務の説明書になっていきます**

1章を構成するテクニックの種類

- ユビキタス言語
- 単一責務
- ドメインオブジェクト
- 値オブジェクト(Value Object)
- ファーストクラスコレクション
- Tell, dont Ask

## Chapter2 場合分けのロジックを整理する

### プログラムを複雑にする「場合分け」のコード
- 区分や種別がコードを複雑にする
区分の数だけバリエーションが発生する

- 判断や処理のロジックをメソッドに独立させる
わかりやすい名前を使う
処理毎にメソッド化する

- else 句をなくすと条件分岐が単純になる
早期リターン, ガード節

- 複文は単文に分ける

- 区分ごとのロジックを別クラスに分ける

- 区分ごとのクラスを同じ「型」として扱う
interface, 多態
- 区分ごとのクラスのインスタンスを生成する

- Javaの列挙型を使えばもっとかんたん

- 区分ごとの業務ロジックを区分オブジェクトで分析し整理する

- 状態の遷移のルールをわかりやすく記述する

## タクマが教えてくれた質問・疑問

> ## 第1章
> - オブジェクトの値を書き換えた場合のデメリットがもっと具体的に知りたい （p35 ）
> - 値オブジェクトは値を変更しないルールがあることはわかっているが、具体的に何がまずいのか
> - p43も関連して、Customersクラスのaddメソッドの返り値が new Customersになっているが、return this だと具体的に何がまずいのか