結合度をちゃんと理解する
注意：「モジュール」＝パッケージ、クラス、関数な様々な単位を表す
コードベースのすべてのレベルで、「凝集度が高く、結合度が低い」ガイドラインに従うようにしてください。
結合度（カップリング、Coupling）
モジュール間の関係の強さ、多さ。
強さ
モジュール結合度（内部依存は最低、プリミティブデータ依存は最高...）と言われる。よく見るやつを意識すればいい。 要するに、変更頻度の多いモジュール・データに依存しちゃうと結合度としては弱くなる。
変更の影響を受けやすいと言える。
多さ
あるモジュールを見た時、依存モジュールが多いほど結合度が高いと言える。
また、あるモジュールを利用するモジュールが多くても結合度が高いと言える。
高結合（密結合）に対する注意
そのモジュールが他の変更影響を受けやすい、もしくは自分の変更影響を他に与えやすくなってしまう。
結合度が高くなる（関係先が増える）ほど、影響範囲は広がってしまう。
影響範囲が広がると...
このモジュールが関係する変更が大変になる。
1部分の変更に対して、結合分だけ他モジュールも変更することになる。
これによってリリーススピードは圧倒的に落ちるだろう。
システム内で秩序のない高結合が溢れかえると...
バグの発生しやすい、変更しにくいシステムが簡単に出来上がる。
なので、できる限り全モジュールで、疎結合（モジュール関係の強さを減らす）を意識しながら作るべきである。
ただ疎結合だけ意識するだけでは保守性の高いシステムは作れない
疎結合だけ意識しただけでは、逆に扱いにくいシステムになってしまう
https://scrapbox.io/files/633481c4637e24001f70eba4.png
凝集も意識して、関連するモジュールを集めて1つのまとまりを作る必要がある
https://scrapbox.io/files/633481a84d6448001d0299c1.png
凝集度...
複数のパーツから論理的に単一な原子単位を形成してる度合い
onigiri.w2.iconのイメージとしては、作られた原子単位の集まりが更なる高レベルの原子単位を作っていくイメージ
パソコンという単位は「CPU」「メモリ」などの構成から作られてて....
更に「CPU」は「半導体」「バス」などのより小さな構成から作られてて...
凝集もこれを繰り返していくようなイメージだと思ってる。
小さな単位からある一つの単位を作り出し、それらの単位を使ってより上位の単位を作っていく
感想
適切にモジュール分割した後、モジュール間の結合を疎結合に保つことは大事そうonigiri.w2.icon
ただ、モジュール内の部品間の結合はある程度強くても良いとも思うonigiri.w2.icon
モジュール間を疎結合・低結合にしているので、変更の影響範囲を絞られる。
モジュール内の実装まで「低結合！低結合！」とやりすぎると、逆にコードが複雑になる恐れあり。
（2022/9/29）
できることなら凝集内部も疎結合が良いけど、やり過ぎて複雑になるくらいならしなくて良いとは思う
そのクラスが利用する別クラスが多いなと感じたら、実装・設計の見直しを考えるべき
その他参考