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