独立したクラス (P265-) †
要約 †
P.265
相互依存はモデルと設計を理解しにくくし、テストや保守も難しくするが、相互依存はすぐに積み重なってしまう。
関連は当然依存で、それに付随するものも全部理解しなければならない。また、引数や戻り値も依存である。
関連が1つあれば、一度に複数のクラスとその間の関連の性質について考えなければならず、依存があればそれらについても気をつけなければならない。こういうことは、関連が増えると雪だるま式にたくさん起こる。
MODULEやAGGREGATEの目的は相互依存の制限である。関連の強いサブドメインをMODULEとすれば、一連のオブジェクトを分離することができるが、半ば狂信的にMODULE内の依存性をコントロールしなければ、MODULEについて多くのことを考えねばならないかもしれない。
モジュールの中でも、依存が加わると設計は理解しにくくなり、精神的負担や開発者が扱える設計の複雑さの制限を増やす。明示的な参照も然ることながら、暗黙の概念(Implicit concepts)はこれを助長する。
洗練されたモデルは、関連がそのコンセプトの基礎的概念を表現できるまで、蒸留される。重要な副集合の中では、プリミティブなライブラリとだけ連携して全てをそれ自身だけで理解できるクラスにより、依存はなくされる。
プログラム環境において、数値型や文字列、コレクションは常に意識の中にあり、事実上知性に負荷を与えることはない。その上、オブジェクトを理解するために覚えておかなければならない追加コンセプトはどれも、精神的な負荷を助長する。
p.266
暗黙のコンセプトは明白な参照と同じくらい重要だ。数値や文字への依存は無視できるが、それらが何を意味するかは無視できない。Paintは色を表現する数値を保持していて、Pigment Colorを新たに作ったとしても新しい概念への依存は増えない。一方、Collection#sizeの整数型が表現するのは単に整数なので、新しい概念を発生させない。
オブジェクトの背後の概念がはっきりするまで、依存は全て疑わしい。吟味は、モデルを分解することから始まる。それには、個々の関連や操作に気をつけることが要求される。モデルとデザインの選択で、依存を少しずつ削りとることができ、普通は０になる。
粗結合はオブジェクトデザインの基本であり、とことんやったほうがいい。不要な概念を図から消してしまえば、単体で理解できる全部入りのクラスとなる。こういうクラスは、モジュールを理解するための負荷を大幅に減らしてくれる
入り組んだ計算を独立したクラスに分解しよう。たぶんそれは、より多くの依存を持つクラスに紐づいたVALUE OBJECTをモデリングすることでできる。
モジュール内の依存は外部への依存より無害であるのと同様に、密結合する二つのクラス間での一連の操作の呼び出しは自然な関連をはっきりさせる。ゴールは全ての依存を消すことではなく不要なものを消すことで、全ての依存を消せない時でも、なくなった依存によって開発者は残った概念的な依存関係に集中できるようになる。
ペイントと言う概念は色(絵の具)と結びついているが、絵の具はペイントがなくても存在できる。この「ペイント」と「絵の具」の概念を明確にして関連を蒸留することで、方方向関連だけが重要であることがわかる。そして、計算の複雑性が一番集まっているところである絵の具クラスは、学習コストが低く単体でテストができる。
P.267
＊＊＊
疎結合は概念の過負荷を減らす基本的な手法で、「独立したのクラス」はその極みである。
依存を除くことは独断で全ての依存を削除してモデルのレベルを下げることではない。この章の最後のパターンは「処理のクロージャ」で、リッチインタフェースを保持しつつ依存を無くすための技術の例...。
担当者(本間)のつぶやき †
出席できなくてすみません。
粒度が細か過ぎかもしれません。後で見直そうと思ってたら、時間をとれませんでした・・・。
みんなの突っ込み †
- いわゆるオブジェクト指向の「低結合性」をドメイン駆動的に言いかえたもの？ -- 佐藤?
