Is this the correct understanding of tight coupling and loose coupling

Question

Coupling mean "dependency". It is the case of "Class A" dependent on "Class B" to get the job done.

Tight Coupling is when "Class A" Use the implementation of "Class B". Loose Coupling is when "Class A" Use the abstraction on "Class B".

Is this the correct understanding or is it oversimplify ?

[This answer](http://programmers.stackexchange.com/a/160267/121080) also explains it pretty well — lethal-guitar, May 14 '14 at 07:58

score 2 · Accepted Answer · answered May 14 '14 at 08:43

Tight Coupling is when "Class A" directly calls "Class B" or an object of "Class B" to done a job. in loose coupling "Class A" calls an abstract class or an object of an abstract class to done a job; so if "Class B" implements mentioned abstract then "Class A" indirectly called the "Class B" without depending on "class B"

as an example think "Class B" is Data layer that provide you services to run queries on SQLServer Db. what will happen if you want to run same application with for example an Oracle DB or MySQL or XML etc. If "Class A" instead of depending on "Class B" just depent on an abstract class like IDBProvider. then you can use "Class A" with any Class that just Implement IDBProvider. this is loosely coupled.

score 1 · Answer 2 · answered May 14 '14 at 08:52

Consider the following example:

// Let's say this method lives in a class MyClass
public void doSomething(Foo foo, Bar bar) {
    foo.prepareProcessing();
    Worker work = foo.createWorker();
    work.dispatchTask(new Task(bar), 12);
    work.start();
    foo.waitForWorker(work);
    foo.finishProcessing();
}

Contrast it to the following:

public void doSomething(Foo foo, Bar bar) {
    foo.runTaskAtPriority(bar, 12);
}

In the first example, classes Foo and MyClass are tightly coupled: MyClass not only depends on Foo, but also on Foo's dependencies, like the Worker and Task classes. Furthermore, MyClass depends on very specific internals of Foo: It has to call several methods in a certain order. It's much more likely that changing something in Foo will also require changing MyClass.

The second example only depends on Foo itself. So if Foo stops using a Worker internally, MyClass doesn't have to care. MyClass and Foo are loosely coupled.

In the end, it's all about knowledge: The more you need to know about a certain class/method in order to use it, the tighter the coupling.

"Depending on abstractions instead of concretions" is a common way to achieve low coupling. But introducing abstract classes/interfaces doesn't automatically reduce coupling - you rather need to think about ways to reduce the possible interactions (knowledge) one class has with another one.

Is this the correct understanding of tight coupling and loose coupling

2 Answers2