ちょうぜつソフトウェア設計入門の要約 第二章
第二章 パッケージ原則
先ほどの障壁をどう乗り越えるかとのちこえるために必要な知識を解説した章
再利用・リリース等価の原則
リリースされたものだけを再利用しなさい。再利用させたければリリースしなさい。
という原則
じゃあ再利用の単位とは？それについて具体的に言及したのが全再利用の原則と閉鎖性共通の原則
全再利用の原則
パッケージ(ここでは、複数のクラスがまとまった単位)の利用者は、パッケージから必要なものだけを選び取ることはできないというもの
この原則は、パッケージ作成者は利用者の利用する適切な単位にパッケージをまとめるようにすべき
と読み替えられる
そしてその適切な単位は、そのパッケージの責務を考えることでわかる
責務ごとにまとまっていることで、再利用も可能で不具合の解決にも役立つ
たとえばECサイトで商品登録機能に不具合があったとしたら、商品にまつわるパッケージを確認していけば良い。
閉鎖性共通の原則
一つの変更が必要な時できる限り一つのパッケージだけを交換すれば良いようにせよという原則。
これが守られていれば先ほどの例だと、以前は問題なく商品登録できていたのであれば前バージョンの商品パッケージに交換すれば良い
またこの原則は、パッケージ内の変更があったときはそのパッケージ内にのみ影響が及ぶとも言える
商品パッケージで同時登録できる機能がリリースされたからといって、会計のパッケージに影響が及ぼされ壊れるということもない
凝縮度・結合度
これらの原則を踏まえると責務から考えて分けすぎず、まとめすぎないようになっていることが重要だと言える
全再利用の原則と、閉鎖性共通の原則を守ると、凝縮度が高く(責務ごとでまとまっている)結合度が低い(関係ないものは含まない)状態になる
つまりこれらは表裏一体であると言える
所感
再利用・リリース等価の原則、全再利用の原則、閉鎖性共通の原則
これらは他書籍だと相反するところがあるので、バランスを取らないといけないとよく言われる
もう少しそのバランスの取り方を理解したい
非循環依存関係の原則
パッケージ同士が循環依存してはいけないという原則。
今までの三原則は、一つのパッケージに関するものだったが、これは複数のパッケージの関係を表している。
循環依存とは、AがBを使っててBがAを使っていること。
循環依存はなぜダメか？
循環依存しているパッケージ同士は、切り離せず(閉鎖性共通の原則)一つの大きなパッケージに複数の責務が混ざった状態(全再利用の原則違反)になってしまう。
循環依存への向き合い方
とはいえ単方向にパッケージの依存の方向を調整できない場合もあるので、そういった際はそれらを一つのパッケージに含めてしまえばよい
そうすればパッケージ間の循環依存は起きなくなる
所感
一つにすると異なる責務のパッケージがまとまってしまうので、それこそ閉鎖性共通に違反してしまうのではないか？
安定依存の原則
パッケージの依存は常に安定したパッケージに向くという原則
安定しているものに依存していれば、依存先の変更に振り回されることがなくなる
安定度・抽象度等価の原則
安定度と抽象度は相関関係があるというもの
ここで指している抽象とは
- 実装詳細を除いたもの(インターフェースや抽象クラスなど）
- 1のように詳細を持たないものだけに依存するロジック
- 時刻や配列などの汎用概念とその操作
- プログラミング言語や標準ライブラリと同等レベルの業界標準
4はクリーンアーキテクチャの外側のように思われるが、実はドメイン層から呼び出しても問題ない
プログラミング言語は何にでもなれる究極の抽象であることを考えれば、違和感はないかもしれない
2章の感想
著者の説明でいまいち腑に落ちない箇所があった
他書籍の解説と比較するなどして理解を深めたい
Discussion