再代入（破壊的代入）を避ける
- finalをつける
フールプールの立場をとる
変更系はクラスのインスタンスを生成し直してをreturnする
どうしてもミュータブル（可変）をとるケース
- パフォーマンスに関わるケース（大量のデータ処理やループでの変更の多い処理など）
- スコープが局所的なケース（ループカウンタやローカル変数など）

memo

ミューテーター
状態変更を発生させるメソッド

tuna 2022/05/04に更新

5章　低凝集

staticメソッドの誤用
インスタンス変数を使う構造にする
- インスタンス変数とそのインスタンス変数を用いるロジックを同じクラス内に閉じ込めた構造が高凝集
- staticメソッドでなくてもインスタンス変数を使ってないメソッドがクラスにあったら注意する
初期化ロジックの分散
- 標準会員のポイントと特別会員のポイントで初回付与ポイントが違う時に呼び出し側でコンストラクタにポイントを渡すのではなく、コンストラクタをprivateにしてファクトリメソッドでポイントの責務をクラスに閉じ込め凝集性を高める（生成ロジックが大量にある場合はファクトリクラスも検討する）
CommonやUtilクラスを無闇に作らない
横断的関心事はstaticに作っても問題ないことが多い
- ログ出力
- エラー検出
- デバッグ
- 例外処理
- キャッシュ
- 同期処理
- 分散処理
結果を返すための出力引数を使わない（引数にクラス型の変数を取得し、その中の値を変える等）
多すぎる引数を避ける
プリミティブ型を中心に設計しない
意味のある単位でクラスを作っていく
デメテルの法則に気をつける
Don't tell ask.
- 呼び出し側がメソッドを呼んでその状態に応じてプログラミングするのではなく、呼び出し側の状態に対応するクラスやメソッドをただ呼ぶだけにする

memo

凝集度
モジュール内におけるデータとロジックの関係性の強さ
staticメソッドの使い所
- 凝集度とか関係ないところ（ファクトリメソッドなど）

tuna 2022/05/04に更新

6章　条件分岐

ネストを深くしない
- 早期returnで条件に当てはまらない場合はすぐ抜ける
属性をswitchで分岐してロジックを記述するのは怪しい匂いの元
- typeなどで分岐していくとtypeの記述漏れ等が発生する
- 他プログラマーが真似たり、同様の分岐ロジックなどが氾濫する可能性もある
属性による分岐分けはinterfaceで対応する（ポリモーフィズム）→ストラテジーパターン
会員種別（ゴールドやシルバー会員など）を分けるにはポリシーパターンが有効
- 条件の部品か
- 部品化した条件を組み替えてのカスタマイズ
引数によって処理を変えるフラグ引数は悪手
- メソッドは単機能になるように設計する。フラグで分岐させない。

tuna 2022/05/04

7章　コレクション

わざわざループを回して自前でコレクション処理をしない。言語に存在する標準関数を使う（車輪の再開発）
早期continue、breakでネストを減らす
- 条件に当てはまったら処理をする、ではなく当てはまらなかったら次のループに移行する。
ファーストコレクションを利用し低凝集を解決する

tuna 2022/05/12

8章　密結合

ビジネスロジックに関わるメソッドを流用すると流用された側の修正によって流用した側のメソッドに影響が及ぶ
単一責任の原則
- クラスが担う責任はたった一つに限定する
- 責務が単一になるようにクラスを設計する
DRYは重複コードであれば必ず繰り返してはいけないというわけではない
- 全ての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない
継承はかなり中して扱わないと危険。基本的に継承は推奨しない。
継承より委譲
ある継承クラスにとって関係があって、別の継承クラスには無関係なメソッドなどが出てくると危険の象徴（どこからどこまで関係があるのかわからないため）
依存関係の図を影響スケッチと呼び、図式化して関係を把握するのもあり
アクセス修飾子はpackage privateを基本にする
privateメソッドが大量にあるクラスは異なる責務が混じり込んでる可能性が高い。適宜クラスを分けて責務ごとにクラス、メソッドを分ける。
表示関連のクラスに表示以外の責務のロジックをのせない
トランザクションスクリプトパターンを避ける
- 手続的なメソッドの羅列をつくらない
神クラスは作らない（責務を分けないでひたすら一つのメソッドに全てを書いていく）
- 責務ごとにロジックを分ける

tuna 2022/05/12

9章　安全性をそこなう設計

デッドコード
- 到達しないコード。可読性の低下、読み手に実行条件があるのではないかと混乱させる。
- また今まで実行されてなかったが仕様変更によって実行されてバグを生む原因になる。
マジックナンバー
文字列型への固執
- "a,b,c"みたいにカンマ区切りでsplit変数を使って利用するなど（CSVはフォーマットなので別）
グローバル変数やデータクラス
- どこからでも書き込めるというのはバグの温床になりやすい
なるべくNullを扱わないようにする
- nullをreturnしない。初期値にnullを入れない。
例外の握り潰し
メタプログラミング
MVCSなどの技術駆動の単位でパッケージングをしない
- ビジネスロジック単位でパッケージングする

tuna 2022/05/19

10章　名前設計

正しくクラス分け（ネーミングする）
- ユーザークラスや商品クラスなどは定義が大きすぎる。もっと明確かつ焦点を当てた特定の名前を持つクラス名とつける。
- 関心事ごとに分離する
命名に大事なポイント
- 具体的で、意味範囲が狭く、特化した名前
- 存在ベースではなく、目的ベース
- 関心事を分析する
- 声に出してみる
  - ラバーダッキング
    - 問題が発生した時に誰かに声に出して説明すると自己解決する
  - ユビキタス言語
    - チーム全体で意図を共有する言葉。またクラスやメソッドなどもそれに統一する。
    - 開発者のみで通じる言葉だったりビジネスサイドだけで通じる言葉は存在しないようにする。
- 利用規約を読む
- 違う名前に置き換えられないか検討する
- 疎結合高凝集になるかチェックする
仕様変更時は適宜名前も変える
- 最初は個人顧客を扱う顧客クラスがあったとして途中で法人顧客も扱うようになったら両方のビジネスロジックを一つにしないで二つにクラスを分割する
会話に出てくる名称がクラスとして存在しない場合は要注意
- 例えばユーザーの状態によってゴールド会員とかある場合にユーザークラスだけで取り扱うのは危険
意図が伝わらない名前は気をつける
- tmpだらけとか、aとかbとか
驚き最小の原則
- 使う側が予想した通りに、予想外な驚きが最小になるように設計する
- countは要素の数を返すだけ。他の処理を交えない
クラスが巨大化する名前は避ける
- ◯◯Managerクラス、◯◯Processorクラス、◯◯Controllerクラス、◯◯Serviceクラスなど
コンテキスト（状況）の違いを考慮する
- 車といっても販売（車本体の価格）を扱うものと、車を使った配送とを同じクラスにすると車クラスが肥大化する。車の販売と車の配送をパッケージごとに分離する。
可能な限り動詞１文字になるようなメソッド命名をする
- 目的語がクラス名となって、それがメソッド（動詞）を実行すると言う形
クラス名 is 状態やクラス名動詞が自然な英語になるようにする
省略された名前はロジックがわかりにくくなるので省略しない

tuna 2022/05/20

11章　コメント

退化コメントになるものは書かない
- コメントに書いた時点のものとその中身の動作に差異が生まれコメントが古くなる状態のこと
- コメントは修正されにくく、呼び出し側の修正までされないことが多いため
コメントにより命名が蔑ろになる
コメントを書くのであれば将来ロジック変更になる時どこで何をすればいいのかを書く

tuna 2022/05/22

12章　メソッド

クラスのインスタンス変数を必ず使うこと
変数は不変をベースにする
呼び出す側がクラスの中身や状態を判断してプログラムをしない。ただクラスに命じるだけになるようにする。（Tell, Don't ask）
CQS（コマンドクエリ分離）
- 取得と変更を同じメソッドに書かないようにする
引数
- 不変にする
- フラグは使わない
- nullを使わない
- 出力引数は使わない
- 引数の数はなるべく少なく
エラーはエラー値やNULLで返さない。言語にもよるが基本は例外で返す。
- エラーを値やエラー用のデフォルト値として返すとそれ自体に意味を持ってしまい、その値だったらという処理を呼び出し側が定義する必要が出てきてしまう（ダブルミーニング）
- NULLも同様。

tuna 2022/05/22

13章　モデリング

特定の目的達成のために最低限考慮が必要な要素を備えたものがモデル
現実世界の出の物理的な存在と情報システム上のモデルが１：１になるとは限らない
- Userというのはプロフィールやアカウント情報（ID/PASSなど）や所属している会社などの情報等、システムの観点で見ると複数にまたがる
- そのためUserという大きすぎる枠組みだと解釈次第で全てUserになってしまう
- 目的達成するための目的駆動で名前設計をするようにして解決する
特定の目的に特化して設計することで変更に強い構造になる（単一責任の原則）
モデルの見直し方
- モデルが達成しようとしている目的を全て洗い出す
- 目的特化したモデリングをする
- モデルに目的以外の要素があったら見直す
モデル＝クラスは必ずしも成り立たない。モデルは１：Nのクラスから構成される。
機能性の革新に貢献するモデルをドメイン駆動設計で深いモデルという

tuna 2022/05/23

14章　リファクタリング

Unitテストのコードを書く
仕様化テスト
試行リファクタリング
IDEのリファクタリング機能を使う
リファクタリングで気をつけること
- 機能追加とリファクタリングを同時にやらない
- スモールステップで実施する
- 無駄な仕様は削除することも検討する

tuna 2022/05/25

15章　設計の意義と設計への向き合い方

変更が困難で壊れやすいコードをレガシーコードという
レガシーコードが蓄積されている状態を技術的負債と呼ぶ
可読性などの一連の品質指標をコードメトリクス（ソフトウェアメトリクス）と呼ぶ
行数が多い場合はメソッドやクラスの分割を検討する
循環的複雑度（サイロマティック複雑℃）。コードの構造的な複雑さの指標。
凝集度
結合度
チャンク

tuna 2022/05/31に更新

16章と17章は振り返りと書籍紹介

tuna 2022/05/31

全体読んでの感想

全体的に今まで設計について勉強してこなくて、やり始めてみようと思ってる人向けの書籍だった
基本はどの設計についての書籍でも言っているように高凝集、低結合、SOLIDが基本。
そこらへんしっかり出来てる人はこの本はスキップしてもいいかもしれない。逆に自信ない人はお薦めできそう。
ちょっと気になった点は、
同じことを何度か繰り返すので内容に対してボリュームが増えてしまってる（大事だから繰り返してるともとれる）
この設計は実はよくない設計です。後に説明します。といった後に、その説明が出てくるまでに長すぎるのと、ずっとその例を使い続けるので気になってしまう。よくない設計ならその時点で説明して後々の例でも出ないようにしたほうがいいと個人的には思った。

1章 ダメなコード

2章 設計の初歩

3章 クラス設計

memo

4章 イミュータブル

memo

5章 低凝集

memo

6章 条件分岐

7章 コレクション

8章 密結合

9章 安全性をそこなう設計

10章 名前設計

11章 コメント

12章 メソッド

13章 モデリング

14章 リファクタリング

15章 設計の意義と設計への向き合い方

全体読んでの感想

1章　ダメなコード

2章　設計の初歩

3章　クラス設計

4章　イミュータブル

5章　低凝集

6章　条件分岐

7章　コレクション

8章　密結合

9章　安全性をそこなう設計

10章　名前設計

11章　コメント

12章　メソッド

13章　モデリング

14章　リファクタリング

15章　設計の意義と設計への向き合い方