前回のふりかえり
第10章①の主旨
- しなやかな設計とは、深いモデリングを補完するもの
- 暗黙的な概念を掘り出し、概念を簡潔かつ明確なモデルにする。洞察とリファクタリングを繰り返し、改良していく。
- しなやかな設計 は開発者が気軽にソフトウェアに変更を加えることが出来、開発の進行に合わせてプロジェクトを加速させられる設計
- しなやかに設計するためのパターン
- 意図の明白なインターフェース
- 副作用のない関数 (これ以外にも色々ある。後述)
第10章 しなやかな設計
表明
表明とは
- 演算を副作用のない関数に分離しても、エンティティ上には副作用を作り出すコマンドが残ってしまっている。
- 必要なのは、副作用を明示的にして、内部を徹底的に調べなくても、設計要素の意味と操作の実行結果を理解できるようにする方法(意味の明白なインターフェースでは不十分) → 副作用のある操作を理解しやすい形で表現するための手法が表明
どうやって表明を実現するのか
- クラスとメソッドについて、3つの条件でオブジェクトの状態を確認する
- 事後条件:メソッドを呼び出すことで保証される結果を記述
- 事前条件:事後条件が成り立つことを保証するために満たさないといけない条件
- クラスの不変条件:あらゆる操作が終わった時のオブジェクトの状態
→ 不変条件・事前条件・事後条件を明確にすることで、開発者は操作やオブジェクトを使用した結果を理解できるようになる → オブジェクトの手続きではなく状態を確認するものなので、テストが容易になる
表明の宣言方法
- 操作の事後条件と、クラスおよび集約の不変条件を直接コーディングで宣言する
- 直接コーディングできない場合は自動化されたユニットテストを書く
- ドキュメントや図の中に記述すること
概念の輪郭
概念の輪郭とは?
- 機能はそのままだと、様々な概念が混在しているので意味を理解するのが難しい。しかし、何も考えずクラスやメソッドを分割してしまうと、機能を無意味に複雑にしてしまう(オブジェクトの粒度は細かければいいわけではない)
- ドメインには論理的な一貫性(つまり概念?)がある。この概念にコードを適合させるよう実装することで姿を現すのが 概念の輪郭
概念の輪郭を見つけ出すには
- 設計要素(操作・インターフェース・クラス・集約)を高凝集・低結合になるように分解する
- リファクタリングを通して、設計の根底にある概念の輪郭を踏まえ、どのように(どのような粒度で)オブジェクトを分割するのかを見極める
独立したクラス
- 独立したクラスとは、低結合を極限まで進めたもの。
なぜ独立したクラスが必要なのか?
- オブジェクトに相互依存関係があると、設計を解釈するのがどんどん難しくなる
- モジュールや集約は相互依存関係を制限するものだが、一つのモジュールであっても依存関係が増えれば設計の解釈は難しい
- 低結合を極限まで進めて、関係のない他の概念をすべて取り除くことで、クラスが自己完結して単独で理解できるようになる。
閉じた操作
- ここでいう「閉じている」というのは、数学の足し算にように、引数も計算結果も実数になる(同じ種類のものが返ってくる?)というニュアンス。
- 閉じているという性質により、操作を解釈するのが大幅に単純化される
- 戻り値の方を引数の型と同じにできる場合は、そのように操作を定義する
- そのように定義することで、他の概念への依存関係を導入することがなくなる
- 閉じた操作は値オブジェクトの操作として使われやすい(エンティティは性質上閉じた状態で操作することが難しい)
思ったこと・気になったこと
- 色んなパターンが矢継ぎ早に出てきて、一個一個の考え方を追うので精一杯...