はじめに

DDDの権威である松岡幸一郎さんの「オブジェクト指向は1回忘れよう。10分でわかる設計のツボ「高凝集/低結合」」という動画を見たので感想とその内容をアウトプットしようの記事です。

該当Youtubeは以下

記事の内容は以下のリンクにございました

どうしたら設計をよくできるのか

エンジニアの永遠のテーマの一つ

参考にすべき原則、パターンはたくさんある

オブジェクト指向の原則

SOLID

デザインパターン

その他原則

抽象度統一原則

KISS

おすすめ書籍

プリンシプルオブプログラミング

色々な原則が載っている

クリーンコード

具体例込みで即効性のある原則が紹介されている

そもそも原則確かに多いなと思う、それを知らないとコミュニケーションがそもそもできないみたいなこともあり
ハードルが高いな〜事前に詰め込むべき知識が多すぎないか...と新人の時は思っていた。

色々考えた結果、これかなというのを見つけた

一つ抑えるだけで、複数の利点を得られる物があるらしい

それが 「高凝集、低結合」

こんなにいいことがあるらしい

英語版Wikipediaより

理解容易性: コードを読んで理解しやすくなる

拡張性: コードを修正、拡張しやすくなる

信頼性: 修正時にバグを埋め込みにくくなる

再利用性: 同じコードを別の場所で再利用しやすくなる

テスト容易性: テストを実施しやすくなる

そんな大事な原則があったなんて、まずはそれを理解しよう！

凝集度、結合度とは

ソフトウェアの品質を表す指標(メトリクス)

1974年に提唱され、以後ソフトウェア工学の標準用語となった

凝集度

モジュール内の要素同士がどれだけ関連しているかを示す指標

クラスの責務、クラスのメソッドとデータの関連の強さ

責務とは、「そのクラスは何をする(表す)クラスか」という問いへの答え

高い方が良い (高凝集)

結合度

モジュール間の依存度の高さを示す指標

依存度が高い→依存先の修正の影響を受けやすくなる

低い方が良い(低結合、疎結合)

凝集度と結合度の意味を理解した！

凝集度は高ければ高いほど良い◎
クラスの責務が明瞭で、誰が見てもこのクラスがどのようなことをするクラスかわかるもの、
人に説明するときに悩まないもの。
クラスの責務と属性とメソッドがちゃんと関連しているかを説明できること。
「Util」や「Service」の名前がついていると怪しい。

結合度は低ければ低いほど良い◎
振る舞いが外側から推測が難しいものは依存度が高い、
一発で見てわからない、コードを先まで読み解かないといけなくなっていて
読んでいる人がその知識を知っていることが前提になってしまっているようなコードは
結合度が高くなっている。

ドメイン駆動設計との繋がり

責務・凝集度の話は設計を考える上で常に重要

アーキテクチャのレイヤー化時に考えることは
「レイヤーによる責務の切り分け」

エンティティ、リポジトリなどの設計を考えることは
「クラスによる責務の切り分け」

とにかく責務を考え、凝集度を上げる

この原則でかなりの領域をカバーできる

アーキテクチャのレイヤーで気にする責務

ドメイン層はドメインのルールや制約を表現する
ユースケース層はユースケースを組み立てる
プレゼンテーション層はクライアントとの入出力をユースケース層との間で変換する
エンドポイントを定義する

エンティティ、リポジトリなどの設計を考える責務

エンティティや値オブジェクトはドメインモデルを表現するのが責務
リポジトリはそのドメインモデルの永続化層とやりとりする

クラス設計時に考えるべき問い

まずは責務を考える

そのクラスの責務は何か？そのクラスは何をする(何を表す)クラスか？

そのクラスのメソッド、属性は、責務とあっているか？

さいごに

設計のレビューなどをするときに気にすべきツボを学ぶことができました。
シンプルだけど本質！といった感じで
頭ではわかったけどこれを実践に移すには経験が必要だなと感じています。
高凝集、低結合 というワードも初めて知ったので常に気を使いながら設計をしてきたいです。