Can a pattern become an anti-pattern? How to avoid the loose coupling mistake
Nobody is debating the benefits of loose-coupling, but far too many SOA architects take the practice too far. Make sure you know when loose-coupling makes sense, and more importantly, when it doesn't.
Loose coupling is always a good idea. After all, what's wrong with abstracting away separate layers of concern, creating pluggability points, making your design more flexible, and creating a software design that can adapt to future changes and enhancements? Loose coupling is a great idea. But just because it's always a great idea, doesn't mean it's always a great practice.
Just because it's a great idea, doesn't mean it's always a great practice.
There is nothing worse than being on a software development project where the architect has just come off a five day training course on service oriented architectures, because that architect wants to refractor every class and method into an interface and an implementation class, all in the name of loose coupling. And while the intention is valiant, the effort put into such an endeavor is not.
So when does loose coupling make sense? Here are three instances when loose coupling is worth the effort.
1. Interactions between physical access layers
If you're application is moving data across a network, the way your application interacts with the lower level transport APIs need to be abstracted away. After all, transport mechanisms can change, network protocols will evolve, and even more importantly, the data transfer format might get switched. For example, one day your application might be sending XML over HTTP, while the next the remote API you are invoking may require a JSON string. If the physical communication layers are loosely coupled, your application can easily adjust to such changes.
2. Interactions between logical software layers
All applications should be developed using, at the very least, a model-view-controller (MVC) type architecture, with those three layers having three distinct responsibilities. More software layers tend to be added to more complex applications, be it a dedicated data layer, a validation layer or security mechanism. But interactions between each of these clear logical layers should be abstracted away. Why? One reason is the fact that as an application scales, some of these logical layers may end up being separated into physical layers. For example, heavy business or database logic might be placed on a separate physical machine, separate from the presentation or view layer. If the various layers are loosely coupled, it would be easy to make this type of a change.
Another reason to loosely couple logical layers is the fact that it makes testing easier, as the various layers can be easily mocked out or have fakes or stubs created that can reproduce another layer's behavior when isolated testing needs to be done. Loosely coupled software layers can make testing easier, which in turn makes isolating and troubleshooting bugs and software problems much easier.
3. A clearly identifiable pluggability point
The third time a loosely coupled interaction makes sense is when there is a clear and obvious pluggability point in your application. For example, your application might use Hibernate to persist data. But there's always a good chance you may just decide to use another ORM tool, or perhaps even just use JDBC. That's a pretty clear plug-in point, where it might make sense to change one implementation of a given function with another. Applications will tend to have a bit more subtle instances for abstraction and loose coupling than something as significant as the ORM tool of choice, but you get the idea. If there is something in your application where it might make sense to swap one implementation out with another, loosely couple the interactions between that component and the rest of your application.
Now that might not be an exhaustive list of when loose coupling makes sense, but it is a pretty good one. If you're on a software project and you see the architect abstracting things away, and blabbering on about loose coupling, ask yourself if the scenario in question falls into one of the three categories above. If it doesn't, try steering the software project in the right direction by asking questions and making sure that loose coupling is being used in the right places and for the right reasons.
Which accepted software patterns have you seen abused and misused? Let us know.
