Difference Between Loose Coupling and Tight Coupling

Yusuf Karatoprak

I have read many articles about loose coupling and tight coupling. I have realized that some programmers have been discussing the differences between loose coupling and tight coupling. I want to talk about the situation from my point of view.

Short Introduction Loose and Tight Coupling

Loose Coupling means reducing dependencies of a class that use a different class directly. In tight coupling, classes and objects are dependent on one another. In general, tight coupling is usually bad because it reduces flexibility and re-usability of code and it makes changes much more difficult and impedes testability etc.

Tight Coupling

A Tightly Coupled Object is an object that needs to know quite a bit about other objects and are usually highly dependent on each other's interfaces. Changing one object in a tightly coupled application often requires changes to a number of other objects. In a small application we can easily identify the changes and there is less chance to miss anything. But in large applications these inter-dependencies are not always known by every programmer or there is a chance of overlooking changes. But each set of loosely coupled objects are not dependent on each other. (Stackoverfow-Jom George)

Code

namespace
TightCoupling
{
public class Remote
{
private Television Tv { get; set;}
protected Remote()
{
Tv = new Television();
}

static Remote()
{
_remoteController = new Remote();
}
static Remote _remoteController;
public static Remote Control
{
get
{
return _remoteController;
}
}

public void RunTv()
{
Tv.Start();
}
}
}

Difficulties

Tight Coupling creates some difficulties. Here, the task of the control object, the object needs to be able to television, the television remote control is dependent on the other phrase. So, what's the harm of the following dependencies:

TV without a remote control does not work.
TV changes the control directly affected by this change.
The Control can only control the TV, cannot control other devices.

Loose Coupling

Loose coupling is a design goal that seeks to reduce the inter-dependencies between components of a system with the goal of reducing the risk that changes in one component will require changes in any other component. Loose coupling is a much more generic concept intended to increase the flexibility of a system, make it more maintainable, and makes the entire framework more "stable".

Code

public interface IRemote
{
void Run();
}
public class Television : IRemote
{
protected Television()
{

}

static Television()
{
_television = new Television();
}
private static Television _television;
public static Television Instance
{
get
{
return _television;
}
}

public void Run()
{
Console.WriteLine("Television is started!");
}
}

We need a managing class that will produce an instance. The instance is generated from the implemented class. The Management Class constructor needs an interface which implements to any Class.

Code

public class Remote
    {
         IRemote _remote;

public Remote(IRemote remote)
{
_remote = remote;
}

public void Run()
{
_remote.Run();
}
}

Usage

class Program
{
static void Main(string[] args)
{

Remote remote = new Remote(Television.Instance);
remote.Run();
Console.Read();
}
}

Advantages

It will save you a lot of time for any project that isn't trivially small, where I define trivially small as less than a couple thousand lines of code (depending on the language). The reason is that once you get past super small projects, each change or update gets harder the more tightly coupled it is. Being loosely coupled enables you to keep moving forward, adding features, fixing bugs, etc.

At a certain point I think any program becomes a nightmare to maintain, update and add on to. The more loosely coupled the design is, the further that point is delayed. If it's tightly coupled, maybe after about 10,000 lines of code it becomes unmaintainable; adding features becomes impossible without essentially rewriting from scratch.

Being loosely coupled allows it to grow to 1,000,000 - 10,000,000 lines of code while still being able to make changes and add new features within a reasonable amount of time. These numbers aren't meant to be taken literally as they're just made up, but to provide a sense of where it becomes helpful. If you never need to update the program and it's fairly simple then sure, it's fine to be tightly coupled. It's even okay to start that way but understand that when it's time to separate stuff out, but you still need experience writing loosely coupled code to know at what point it becomes beneficial.; (From Stackoverflow-Davy8)

It improves testability.
It helps you follow the GOF principle of Program to Interfaces, not implementations.
The benefit is that it's much easier to swap other pieces of code/modules/objects/components when the pieces aren't dependent on one another.
It's highly changeable. One module does not break other modules in unpredictable ways

Summary

As with all OO design, there are trade-offs you have to make; is it more important for you to have highly modular code that is easy to swap in and out? Or is it more important to have easily understandable code that is simpler? You'll have to decide that.

References

http://stackoverflow.com/questions/2832017/what-is-the-difference-between-loose-coupling-and-tight-coupling-in-object-orien

http://stackoverflow.com/questions/2868627/why-should-a-web-architecture-be-loosely-coupled

Loose CouplingCouplingTight Coupling

13 Comments

Join the conversation! Your thoughts help the community grow.

Luke Davis7y ago
I'm going to 50% disagree. There is a time and a place for both. A lot depends on the dependency of information which needs to be transferred between classes or modules. In a loosely coupled system ideally neither class knows much of the other, which means any interaction between the two systems must pass all required information between them since no pre-existing knowledge can be inferred. If we take the human skin example the reason you don't change skins like you change a shirt is because of the information between the body and skin which occurs. Blood, O2, Water, Nerves, sweat etc etc etc. The reason skin is tightly coupled is because to change the skin whenever you feel like requires an inordinate amount of information to do, hell skin grafts are major operations. I'm not even going to go into the issues that come into data integrity, persistence, rollback and maintenance that goes into loosely coupled modules that shouldn't be loosely coupled. A basic rule of thumb is if the data requirements between classes/module is light then loosely couple. If you have to pass large amounts of information between classes (i.e method interfaces with 5+ non-primitive object parameters) you should be looking at tight coupling. I tend to think of things as breaking up black boxes into the smallest possible number of black boxes until the overhead of passing and managing information between black boxes isn't justified if it is broken into even smaller black boxes.
Krishna Reddy B V9y ago
Great, It's really helpful !
Subhajit Giri9y ago
This is a very good article.It helps me a lot.Thanks.
Yusuf Karatoprak14y agoedited
Mahesh said that:" The coder must see the big picture and entire architecture and how various classes / components are glued (loosely) together" it must be a result of my article. whole project needs to good start point which are seeing big picture, entire architecture etc. Thanks any best regards...
Mahesh Chand14y agoedited
To add Sam's point, one of the major disadvantages of loose coupling is, a coder must be experienced and project must follow design standards. If coder does not understand the concept, they will end up breaking things. The coder must see the big picture and entire architecture and how various classes / components are glued (loosely) together.
Vithal Wadje14y ago
good one
Yusuf Karatoprak14y agoedited
Thanks Sam; i agree with your opinion about disadvantages of loose coupling. But it is a kind of habit to use loose coupling. if a programmer uses loose coupling , you will have a good habit. Also i guess all small projects can be grow with unpredictable. However, it is your choose. if you have small one, you will use tight coupling. But you must imagine this project can be discovered by a new customer who want to add new features...
Rohatash Kumar14y ago
Thank you.Yusuf
Sam Hobbs14y agoedited
Thank you, Yusuf. I agree with everything. I hope this helps many people. I think you will agree that a disadvantage of loose coupling is that it requires more work. That can be a problem for small projects that grow into large ones. It happens, correct? I think you almost make the point that when a small project grows into a large project tight coupling can become very expensive and that is why it helps to invest the extra time in using loose coupling even for small projects. And I think it helps for management to understand that the investment can save money. Mamagement needs to understand that developers that use loose coupling from the beginning are usually more cost effective than developers that throw something together real fast.
Yusuf Karatoprak14y ago
You are encouraging me to write new one. Thanks alot again...
Dinesh Beniwal14y ago
Good Start Yusuf.
Yusuf Karatoprak14y agoedited
Thanks alot Mahesh. i will prepare new articles about architecture from my point of view .
Mahesh Chand14y ago
Welcome Yusuf! ASP.NET MVC is a perfect example of a working loosely coupled architecture.