【ソフトウェア開発設計】

「良いコードと悪いコードで学ぶ設計」
1.悪い設計例
・連番や技術の名前で命名していて伝わらない
・ロジック離れすぎていて、再実装してしまう設計
・深すぎるネスト
・初期化忘れ

2.悪い設計の対処法
・意味が通る名前にする
・変数を使い回さない
・処理は変数を使ってベタ書きではなく、関数の呼び出しにする(recoveryやdamageなどなど)
・関数たちをさらに抽象化してまとめられ、パラメータ(変数)も付けられるのがクラス

3.設計の基本
・属性と機能(データと操作)はセットでクラスを作る
・Moneyクラスなど、現実世界に即したものをまとめる
・finalをつけて再代入できないようにする(引数も)
・int型やString型などプリミティブ型は用いず、作ったクラス型をreturnする
・現実には有り得ない数値は、エラー処理をする(現実に即す)

4.不変のメリットデメリット
・インスタンス化を都度するのでバグが起きずらい
・基本は不変がいい
・可変にする場合は、値が外れた時にエラーが出るよう例外処理を書く

5.低凝集
・staticは多様しない。定義した変数はなるべく使う設計になるのが理想
・例えば魔法力だとデータにしてしまいそうだが、魔法力という概念をクラス化して魔法を操作するロジックを入れ込んでいく（回復や使うなど）
・たくさん「.」をつける書き方はしない。どこでバグが発生したのかわからないから。その時は、関連するクラスにメソッドを追加してしまうのが良い。

6.条件分岐
・ifのネストやelseを使う見通しが悪い。なので、毎度returnすることで見やすくなる。
・条件分岐はswitchじゃなくてもできる!!まずはinterfaceを導入!!し、クラスたちをさらに抽象化しよう

7.コレクション
・ifなどを使ってネスト深くするんじゃなく、matchなど標準で装備されてるコレクションを利用する
・if()は、すぐにcontinueやreturn、breakなどで処理ごとに抜けるのが見やすい

8.密結合
・同じコードを書かないよう共通化する時「ビジネス概念が同じかどうか」を判断する。異なる場合はコードが似てても共通化しない
・実は継承は密結合を産んでしまうからよろしくない▶︎委譲を使う
・publicは使わない！
・１クラスせいぜい200とか
・アーキテクチャ学びたいな

9.名前
・ビジネスの目的にあった名前をつける
・省略はものによる
・単一責任の原則に従う

11.コメント
・コードを説明しない
・機能を追加したらコメントも更新
・仕様変更を促すコメントにする
・ドキュメント機能が便利なので使うと良い