疎結合とは何か？という話を最近軽く考えていたので、軽くメモる。
１）実装的に分離していること
メッセージ通信やDIによって分離している状態。
簡単に判別できるとしたら、単独でそのソースコードがコンパイルできること。
実装的に分離できるのであれば、設計上は当然分離しているので、あえては言わない。
しかし、この条件からすると、他のクラスの管理下にあるプロトコル、インターフェイス、その他の抽象を装備してしまうと、疎結合度は下がるだろう。（密結合度が上昇）
https://qiita.com/BlueEventHorizon/items/211dc826e2e86ed8c8d2
のUML図を参照のこと。
先月博多で同じDIでも種類が違うぞ、この話を微妙に熱を込めて語ったのにはこんなわけもある。
２）責務が適切に分離されたインターフェイスが定義されていること。
実はこちらの方が大切で、インターフェイスが適切に定義されていれば、少々「実装的に分離していること」がダメでもなんとかなる。クソなインターフェイスを作ると死ぬのが定石。
あえては言わないが（言ってる・・・）この結果分離されたものをクラスとか関数とかいう。
世の偉いエンジニアの方達には違うと言われそうだが、SRP：単一責任の原則は基本的にはそういうことだと認識している。
https://qiita.com/BlueEventHorizon/items/a0144ef9ac20e587d288
参照のこと。
分析設計は、 MECE で考えられるというのもとても重要なスキルだと思う。というか、（大きく言えば）世の中を分析・設計するのがエンジニアリングであるので、当然考え方は似てくるだろう。
なので優秀なエンジニアは、優秀なデザイナーと同じく、世の中の問題を解決できる力がある（のかもしれない）
おわり