内容
遅ればせながらミノ駆動本を読み切ったので自分なりの解釈で要点をまとめた。
オブジェクト指向全体
脱プリミティブ。最初はびびるかもしれないが抽象化単位で値オブジェクト（値クラス、Moneyとか）を作る
処理はクラス側でやらせる.クラス内部は知らなくても実装できるようにする
ストラテジパターンでSwitch文を減らす
早期return/continue/breakでネストを浅くする
nullは使わない(空の状態を定義する)
メソッドの引数は不変にする
フラグ引数は使わない
出力引数使わない
値オブジェクトでreturn
エラーをオブジェクトで表さない.エラーはスローする
個別クラス設計
- 値オブジェクト
- 現実世界に想定されないメソッドは作らないこと
- 完全コンストラクタ
- 必ずインスタンス変数を初期化する
- ガード節を設けて不正状態に陥らないようにする
- インスタンス変数は基本final
- privateメソッド
- 引数は値オブジェクトで取る
ファーストクラスコレクションパターン(コレクション系のクラス設計)
- コレクションの実装はプログラミングの機能を使うこと
- 個別クラス設計の内容も盛り込むこと
- 低凝縮
- コレクション操作に必要なメソッドを集める
- メソッドの内部では不正状態にならないようにする
- 外部に渡す時には変更ができないように渡す
目的駆動名前設計
役割的なものをベースに名前づけする。基本的には私はローワーキャメルで
変数名に困ったら...
- 会話で出てくる形容詞+名刺に注目する
- 利用規約などでどう表現しているかでビジネスロジックを掴む
一つの名前でクラス作ってしまうと問題になる可能性があるので、同じ”商品”でも役割ごとにクラス設計はかえること(関心の分離)
メソッドでも関心ごとの分離
-
関心ごとが多いメソッド例AdditemsToParty -> Add Item to Party -> PartyItems(Class) がAdd(item)メソッドを持つ
-
Booleanでも同じように Party is Empty -> PartyがisEmptyメソッドを持つ
考え方
パレートの法則：20%が80％の利益を生み出している
コアドメイン：ビジネスのコアドメイン把握
コンウェイの法則：組織とシステム構成が似てしまうこと.社会のコミュニケーションコストを反映したもの
リファクタリング
仕様把握のためにテストケースを作成する
テストケースを失敗、成功させる（テストケースの正当性確認）
理想のクラス設計をして既存コードをちょっとずつ理想のクラス設計の方に移す