疎結合って何？

Question

JAVAを勉強している者です。説明が下手ですいませんが、以前の質問に

役割ごとにカテゴライズされた各レイヤー間にインターフェース（契約）を設けることによって、各レイヤー間を疎結合にし（依存度を低くし）、変更に強いアプリケーション作ることができる

これがインターフェースを利用する最大のメリットと言っても過言ではないと思います。

と出てきたんですが、「疎結合」って何なんでしょうか？

ネットをみても「それぞれの機能ごとに分けられた塊のようなもの」とか「依存度を低くする」とか書いてあるんですが、なんなのかよくわかりません。 （APIのこと？）

私はまだ勉強不足だと思いますが、そもそも依存度を低くするというのは、どういうことなんでしょうか？

わかりやすいような例や例えで教えてくれませんか？ 
できれば身近な例を挙げて教えてくれませんか？ 
よろしくお願いします。

Answer 1

家電製品を使うとします。
たぶん、家の中にコンセントがありますよね。そこに家電製品を指せば、家電製品が使えます。
ここで、自分で家電製品の構造などを分かっている必要が無いということに着目してください。とにかくコンセントを挿せば、家電製品は使えるという認識が私たちにあります。
実はこれが疎結合です。

実際は、家のコンセント内部はいろいろな経路を通って最終的には電力会社から供給されている電気を使えるように配線されているはずで、家電製品はその種類、メーカーによって様々な構造をしています。
しかし、とにかくコンセントを結合部として両者を関連させてしまえば、両者は上手く動作するわけです。
そして、両者はコンセントを結合部として関連できるように設計、開発されており、コンセントさえあれば、その内部構造を意識しなくてもよいようになっています。

上記のように、それぞれのことを深く知っていなくても、便利に物事が進むようなイメージが疎結合と認識して頂ければそこまで間違っていないでしょう。

「疎」とは「密」の逆を表す言葉です。「集まっている」のではなく「離れている」状態をイメージして下さい。
「結合」にはいろいろな意味がありますが、この場合は「両者の関連」であると考えれば良いと思います。
つまり「疎結合」とは両者間の物事の関連が薄く、できるだけ両者間が離れているということです。
「依存」とは「他のものによりかかり、それによって成り立つこと」です。恋人同士の関係などを想像して頂ければ分かり易いかと思いますが、例えば束縛が強いカップルは依存度が高く（密結合）、男女それぞれの自由度が高いカップルは依存度が低いことになります。（疎結合）
もうお分かりかと思いますが、「疎結合」とは「依存度が低い」ということと同義です。

上記家電製品の例で言えば、コンセント内部と家電製品は、コンセントを通じてのみ関連しており、それぞれは独立しているという意味で疎結合であるという事ができ、同時に両者間の依存度も低いことになります。取り外しも容易ですしね。

密結合についても考えてみましょう。
「この家電製品は使うために赤のコードをコンセントの右側に入れて接着剤で固定し青のコードと黄色のコードを絡めたうえでコンセントの左側に入れる」と言われたら困りませんか。これはその家電製品の使い方がその独自の内部構造に依存してしまっていることになります。
しかも実際にそれを実施したとして、接着剤を使ってしまうとコンセントとの結合は文字通り密になり、切り離せなくなります。そうすると、その作業をしてしまったコンセントはその家電製品専用になってしまいますね。切り離すこともできると思いますが、面倒です。
結構不便ですよね。でも車やエレベーターなど、専門家しか中身を確認しないような機械は、まだまだ内部構造としては上記のような感じで専門技術者が配線などを行っていると思います。専門家以外の人が車内の全ての配線を外そうものなら、その内部構造が分かりませんから、再度配線をしなおすことは難しいです。
これが密結合のイメージです。

もし、コンセントというものが発明されていなかったら、家電だって車やエレベーターのように自分で配線をしなければならなかったかもしれませんが、コンセントというインターフェースがずっと前に定められたおかげで、私たちは便利に家電製品を使うことができるのです。

概念としては上記のような感じだと思います。
あとはそれをコーディングで表せるかどうかということになります。

Answer 2

こんにちは。

以前の質問の文脈の「インタフェース」は、それを継承したクラスはその「インタフェース」を通じて操作できるの意味と思います。
つまり、たくさんの異なるクラスの使い方を統一できるものです。

次に、例えばAPIはApplication Program Interfaceの略です。こちらにも「インタフェース」がでてきます。この文脈のインタフェースはもう少し広い意味を持ちます。何らかのソフトウェア・モージュール間で何か要求やデータをやり取りするための約束事を決めたものです。

さて、そのソフトウェアをある程度まとまった機能に分解したものがモジュールです。例えば、ファイル操作モジュールや表示モジュールなど、様々なモジュールに分解されます。（分け方はソフトウェア毎に異なります。）
単独のクラスもモジュールの一種ですが、複数のクラスをまとめたものをモジュールと呼ぶことの方が多いと思います。

モジュール分解することで、何が嬉しいかというと、全体設計と詳細設計を分離することができ、最初から細かいところまで全て考えないで済むことですね。
大雑把な部分を設計し、次に詳細設計を行うという複数のステップに設計作業を分解できるため、大規模なものを設計できるようになります。

そして、モジュールとモジュールの間のインタフェースを設計する際に、お互いのモジュールの内部構造や動作が相手のモジュールの動作にできるだけ影響しないように設計することで、各モジュールを独立して開発できるようになります。
すると、それぞれに別途人員を投入できるため、より多くの人数をかけてソフトウェアを開発できます。（ということは短期間で開発できると言うことです。スピードは命ですので大切なことです。）
この「お互いの細かい内部構造や動作が相手方にできるだけ影響しないように設計された状態」を疎結合といいます。

さて、逆の状態を想定してみましょう。
片方のモジュールの実装を少し変更しただけで、別のモジュールの動作に影響する場合、その影響先のモジュールも変更が必要になります。するとその別のモジュールの変更された動作が更にまた別のモジュールの動作へ影響することもありえます。どんどん影響範囲が広がるため、頭が痛いですね。

なので、モジュールとモジュールの関係はできるだけ疎結合になるようインタフェースを設計するのが、望ましい設計です。

Answer 3

プログラムを作る上で、どのようにクラス分けを行うかという設計の話です。

例えとして、とあるシステムを作っていると仮定して進めていきます。
CSVファイルの顧客データを集計して売上を求めるプログラムを書く事になりました。

以下のメソッドを用意したクラスを作成しました。

• 引数を元にファイルを読み込む
• (CSVファイルなので)改行とカンマでぶった切って連想配列を作る
• 売上は3個目のカラムなので、for文で回しながら売上を結果変数に足していく

最初はこれで良かったのですが、上司が満足することもなく、次々と要望が増えていきます。

• 顧客当たりの平均売上高を出してくれ
• 売れ筋商品は何か？
• 先週に比べて売上がよくなった製品は何か？

あなたは上司の要望を元に次々とプログラムを肥大化させていきます…
ここまでが前提条件とします。

---

さて、社内のIT化が進みました。
古臭いCSVファイルではなく、今後はJSONファイルに変更するからロジックの修正頼むわ。
でも、まだ移行期間だからCSVファイルでも受け取れるように既存ファイルはそのままで頼む。

どうしますか？
現場でよく行われるのはコピペでJSON版の集計プログラムを作ってしまうことですが、これはバッドノウハウ。
全く同じ集計ロジックが2箇所になるので、集計ミスのバグを修正するためにあっちも直しこっちも直しという風になります。

しかし集計ってデータという連想配列的なものさえ用意出来れば、
ファイルの実体が何であろうが同じではありませんか？
そこで下記の3モジュールに分けて管理する方法を採用します。

• データ：JSONファイル
• データ：CSVファイル
• 処理：集計

集計クラス君に、データのオブジェクトをぶち込んでやると、集計結果が帰ってくるように修正しました。
データの2クラスにはインターフェースを用意して、get_dataというメソッドを叩くと連想配列で値が帰ってくる仕組みを採用しました。

コピペせずに済みましたね。
めでたしめでたし。

…というわけで、今まではCSVファイルの読み込みと集計結果を出すことを全て1クラス内で行っていましたね？
これを密結合と呼びます。

今回の集計クラスは、「インスタンスや引数さえくれれば同じように仕事するぜ」というクラスになりましたね？
このようにモジュール毎に分離されていることを疎結合であると呼びます。
この疎結合の集計クラスを利用すれば、CSVやJSONに限らず、例えExcelファイルになろうが、データベースになろうが、同じように扱えるはずです。

Answer 4

アプリケーションを作るプロジェクトをeclipseで開発されているのであれば、
プロジェクトの環境にいろんなライブラリを追加しないと、
動かせないアプリケーションは、ライブラリがないと動かせないため、結合度合いが高い。

言い換えれば、そのライブラリがないと動かないということは、ライブラリへの依存度合いも高い。

一つのクラスの単位でも、いろんなクラスをインポートして、作ったクラスは、インポートしたクラスとの結合しているため、インポートしたクラスの仕様が変わった際に、そのクラス自体も変更する可能性が高い。

疎結合とは、結合度合いが過疎ってる、と捉えると、依存度が低いクラス、アプリケーションとなる。

具体的には、クラス単位では、インポートするクラスやメソッドのパラメータの数が多い場合、依存度、結合度が高くなり、インポートするクラスやメソッドのパラメータが少ない場合、依存度、結合度が低いし、
アプリケーションの単位では、追加するライブラリが多い場合、依存度、結合度が高く、
追加するライブラリが少ない場合、依存度、結合度が低いと言える。
なお、ライブラリの他にも環境変数などの設定も、これらに含まれることもあり、上記で説明仕切れているかというと、そうでもないので注意が必要。
Javaでは、DI(Dependency Injection)などが代表される技術で、インターフェースやアノテーションプロセシングが使われており、ルールベース、規約によるプログラミングができるようになると、良いのではないか。

Answer 5

「疎結合」って何なんでしょうか？

【疎結合】
店長「これ、お前さんの勤務シフトな」
バイト「あざーっす」

【密結合】
店長「勤務シフトは掲示板で確認してな～」
バイト「うぃーっす」

/*
プログラミング的にかつ大雑把にいうと、
グローバル変数ばんばん使うのが密結合で
パラメータ変数を使ってるのが疎結合かなあ。
*/

依存度を低くするというのは、どういうことなんでしょうか？

【依存度が高い】
交通費の清算はこの書式で書いてあの窓口に出してください。
担当者は誰それで、受付時間は云々

【依存度が低い】
交通費の清算は秘書さんにお願いする。

/*
これも大雑把にいうと、なにかをする際にそれについて
知らないといけないことが多いのが依存度が高いということ。
少ないのが依存度が低いということ。
そういう意味で、依存度を低くするためにAPIを用意する
という表現はあると思います。
*/