密結合
Tight Coupling
プログラムの各パーツが複雑に絡み合い、一部を変更しようとすると他の部分まで影響が及んでしまうガチガチな構造のこと。システムが依存し合っている状態を指します。
🐾 猫で例えると？
茶トラがアメショの体にまるで溶け込むかのように、必要以上にべったりとくっついています。アメショが少しでも寝返りを打とうものなら茶トラも連動して回転してしまうこの状態は、まさにシステム開発における「密結合」の象徴です。お互いの境界線が曖昧で、どちらか片方だけを独立して動かすことが許されない、愛くるしいけれど運用には少し困ってしまう関係性です。
🐾猫あるある：IT現場の日常
- 2匹が複雑に絡まり合って境界線が不明：システムを構成するプログラム同士の依存関係が強すぎて、単体での切り離しやコードの解読が極めて困難になっている状態。
- 一方が動くともう一方が必ず連動する：特定のモジュールに変更を加えた際、全く関係のないはずの別モジュールにまで予期せぬ影響やバグが波及する現象。
- 膝の上の重みで身動きが取れなくなる：一部のコンポーネントを修正またはアップデートしようとするだけで、システム全体の動作を停止させなければならない設計構造。
💻 アプリ・Web開発における「密結合」とは？
システム開発において、機能Aを修正するために、全く関係ないはずの機能Bのコードまで書き直さなければならない…そんな経験はありませんか？これが密結合の典型的な弊害です。クラスやモジュールが互いの内部構造を深く知りすぎていて、直接的に命令し合うような設計になっていると、このような硬直化したシステムが出来上がります。
短期間で小さなアプリを作る分には、密結合でもコードが書けるため便利に感じるかもしれません。しかし、機能が肥大化するにつれて、少しの修正が予期せぬバグを引き起こすようになり、テストの工数も爆発的に増えていきます。エンジニアにとって「変更が怖い」と感じるシステムは、ほぼ間違いなくこの密結合が原因です。
⚠️ 密結合の仕組みとリスク
密結合の何が問題かと言えば、「再利用性」と「テストのしにくさ」に尽きます。
// 密結合の悪い例
class UserSystem {
constructor() {
// 内部で直接、特定のデータベースクラスに依存している
this.db = new MySQLDatabase();
}
}上記のように、システムが特定のデータベースやライブラリと直接くっついていると、将来的にそれらを変更したい時に、システム全体を書き換える必要が出てきます。猫で例えるなら、「茶トラとセットでないと動かないアメショ」を作っているようなもので、これではアメショ単体で活躍の場を広げることができません。
🛠️ 疎結合（そけつごう）へのアプローチ
目指すべきは、パーツ同士の結びつきを弱くする「疎結合」な設計です。各パーツがインターフェース（約束事）だけを共有し、内部の実装を隠蔽することで、互いの独立性を高めます。
- インターフェースを介してやり取りする： 直接クラスを呼び出すのではなく、あらかじめ決めたルール（インターフェース）を通すことで、中身を差し替えてもシステム全体に影響が出ないようにします。
- 依存の注入（DI）を利用する： クラスの中で直接データベースを作るのではなく、外側から「これを使ってね」と機能を与えるようにします。茶トラの世話を誰が担当しても良いように、担当者を外から割り当てるイメージです。
- 責任を明確にする： 1つのクラスに多くの役割を持たせず、猫なら猫の役割、飼い主なら飼い主の役割と、責任を分離することで、変更の影響範囲を最小限に抑えます。
茶トラとアメショがベタベタにくっついている姿は非常に癒されますが、システムにおいては「ほどよい距離感」が平和への近道です。いつでも綺麗に切り離せて、独立して動くことができる。そんなスマートな設計を心がけることで、変更に強く、長く愛されるシステムを作っていきたいですね！