Why is loose coupling good

Alternatively, if you have bet the farm on smaller services then you will need a very strong story around failure, so services can cope with the inevitable timeouts and transient errors. In re-drawing service boundaries, there can be a trade-off between different types of coupling. Process coupling happens when services start to take on too many distinct responsibilities. This gives rise to bloated service implementations that become difficult to scale or change.

Implementation coupling describes services that share implementation detail as opposed to contracts or schemas. A good example here is where one service uses the client library of another to communicate with it. This binds services to a specific language or framework if they want to collaborate.

APIs that leak implementation detail in terms of platform-specific constructs can also cause implementation coupling as any collaborating service will need to implement the underlying technology. Finally, there is location-based coupling , where a service expects a resource to exist in specific location. This is normally addressed by some form of broker or service locator that maps a series of logical destinations to their physical locations.

Loose coupling is often associated with stable development, though it tends to have a wider impact over time. In a tightly coupled system, your performance is largely dictated by your slowest component.

For example, microservice architectures with services that collaborate via HTTP-based APIs can be vulnerable to cascading performance problems where one component slows down.

If your services are decoupled, you will have more freedom to optimise them individually for specific workloads. Your ability to scale is also determined by your least elastic component. Improve Article.

Like Article. Box int length, int width, int height. Next Cohesion in Java. Article Contributed By :. Easy Normal Medium Hard Expert. Writing code in comment? Please use ide. Load Comments. What's New. Most popular in Java. Since there are not a million different versions of a million different interfaces for each resource, the amount of data that needs to be secured and updated could be reduced dramatically. Loose Coupling, in effect, leads to a much more secure ecosystem.

Finally, smart and dumb components are largely isolated from one another, reducing over fetching. In other words, smart components that require more knowledge or data to function can do so by talking to a centralized API. Ultimately, Loose Coupling leads to decreased interdependency between components and reduces the risk of breaking changes. If Loose Coupling has so many benefits, why even consider Tight Coupling? The primary benefit of Loose Coupling is that resources are decoupled from the interface to allow for greater amounts of interoperable, extensible APIs and resource schemas.

Not all services require this, however. There are some cases where one has a single resource and a single interface of a single type. In such a case, singular purpose APIs are often tied to single-use cases and single workflows. Loose Coupling also introduces greater complexity to a system. Some workflows only utilize one device, one interface, and one API.

If only a single implementation is planned, Tight Coupling could make for a much simpler development effort. While Tight and Loose Coupling are certainly the most apparent styles, there is another type of coupling. Non-Permanent Coupling is technically a hybrid type of coupling that fits into neither category.

Non-Permanent Coupling could use time or location-based factors to couple or decouple components. In practice, it still often falls under the umbrella of either loose or tight coupling, but the behavior is unique enough to be defined here separately. Temporal Coupling is the idea that resources can only be used by one resource when another resource has answered the initial request. The resource and the interface are entirely decoupled until a time-limited couple is created.

While this should be avoided most of the time, there are some examples in which this might be valid. A security application managing remote access to a workspace, for instance, might use time-coupling to restrict access to the elevator connection API until the credential service authorizes the requesting user. Related to this is Location Coupling , a paradigm where the resource is coupled to an interface dependent on the proximity of the two.

For instance, a local services API might be tightly coupled to being in close proximity to the resource, such as requiring someone to be in the office and accessing via a known and trusted machine to access the resources. Mexican Explanation: In the above example, all three classes are loosely coupled.

It simply means that you can use the food interface to provide services by injecting any of the implemented services. When two classes are highly dependent on each other, it is called tight coupling. It occurs when a class takes too many responsibilities or where a change in one class requires changes in the other class. In tight coupling, an object parent object creates another object child object for its usage.

If the parent object knows more about how the child object was implemented, we can say that the parent and child object are tightly coupled. Example: Imagine you have created two classes A and B, in your program. If you make any changes in the volume, then the same changes will reflect in class B. Hence, we can say both the classes are highly dependent on each other and are tightly coupled. Explanation: In the above example, class A and class B are bound together and work with each other as a team.

The following table lists the differences between loose coupling and tight coupling. In a nutshell, loose coupling in Java is much better as compared to tight coupling. It provides better flexibility and reusability of code. As the two classes are independent of each other, it makes changes in the code very easy.