As the name suggesting loose coupling means reducing dependencies of a class that use a different class directly. Loose coupling promotes greater reusability, easier maintainability. On the other hand tight coupling, classes and objects are dependent on one another. I must say that, tight coupling is usually bad because it reduces flexibility and re-usability of code and we are not able to achieve complete object originated programming features.

What is Tight Coupling:-

As par above definition a Tightly Coupled Object is an object that needs to know about other objects and are usually highly dependent on each other's interfaces. When we change one object in a tightly coupled application often it requires changes to a number of other objects. There is no problem in a small application we can easily identify the change. But in the case of a large applications these inter-dependencies are not always known by every consumer or other developers or there is many chance of future changes.
Let’s take a shopping cart demo code to understand the tight coupling.

Problems in above code:-

Tight Coupling creates some difficulties. Here, OrderTotal () methods is give us complete amount for the current items of the carts. If we want to add the discount features in this cart system. It is very hard to do in above code because we have to make changes at every class as it is very tightly coupled.

What is Loose Coupling:-

Loose coupling is a design strategy which allows us 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. It’s all about thinking a problem in generic manner and which intended to increase the flexibility of a system, make it more maintainable, and makes the entire framework more stable. Following is a example shows how can we make the changes to achieve loose coupling.

Loose Coupling advantages

This is a small code example, but in the large project is will be very hard to make those changes in every class. It will save you a lot of time for any project. 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. It improves testability. It helps you follow the GOF principle of Program to Interfaces, not implementations.The reason is that once you get past super small projects, each change or update gets harder the more tightly coupled.