What is the difference between loose coupling and tight coupling in the object oriented paradigm?

Question

Can any one describe the exact difference between loose coupling and tight coupling in Object oriented paradigm?

Answer 1

Explanation without ANY code

Summary Example:

The Hat is "loosely coupled" to the body. This means you can easily take the hat off without making any changes to the person/body. When you can do that then you have "loose coupling". See below for elaboration.

Tight coupling (Detailed Example)

Think of your skin. It's stuck to your body. It fits like a glove. But what if you wanted to change your skin colour from say white to green? Can you imagine just how painful it would be to peel off your skin, dye it, and then to paste it back on etc? Changing your skin is difficult because it is tightly coupled to your body. You just can't make changes easily. You would have to fundamentally redesign a human being in order to make this possible.

• Key Point #1: In other words, if you want to change the skin, you would also HAVE TO change the design of your body as well because the two are joined together - they are tightly coupled.

God was not a good object oriented programmer.

Loose coupling (Detailed Example)

Now think of getting dressed in the morning. You don't like blue? No problems: you can put a red shirt on instead. You can do this easily and effortlessly because the shirt is not really connected to your body the same way as your skin. The shirt doesn't know or care about what body it is going on. In other words, you can change your clothes, without really changing your body.

• That's key point #2. If you change your shirt, then you are not forced to change your body - when you can do that, then you have loose coupling. When you can't do that, then you have tight coupling.

That's the basic concept in a nutshell.

Why is all of this important?

It's important because software changes all the time. Generally speaking you want to be able to easily modify your code, without changing your code. I know that sounds like an oxymoron, but please bear with me.

Practical Examples of Coupling in When Coding

• CSV/JSON/DB Examples: If somebody wants their output in a CSV file rather than JSON etc., or if you want to switch from MySQL to PostGreSQL you should be able to make those changes extremely easily in your code, without having to rewrite the entire class etc. In other words, you do not want to tightly couple your application with a specific database implementation (e.g. Mysql) or to a particular output (e.g. CSV files). Because, as is inevitable in software, changes will come. When they do come, it's much easier if your parts of your code are loosely coupled.

• Car Parts Example: If somebody wants their car in black, you shouldn't have to redesign the entire car in order to do that. A car and its spare parts would be a perfect example of a loosely coupled architecture. If you want to replace your engine with a better one, you should be able to simply remove your engine without too much effort and swap it for a better one. If your car only works with Rolls Royce 1234 Engines and no other engines - then your car will is tightly coupled to that engine (Rolls Royce 1234). It would be better if you changed the design of your car so that it will work with any engine, so that it is a bit more loosely coupled with it's components. Even better would be if your car could work without needing an engine at all! Some amount of coupling is going to happen, but you should work to minimise it as much as you can. Why? Because when requirements change we should still be able to deliver good quality software, very quickly and we are aided in that goal by loose coupling.

Summary

In short, loose coupling makes code easier to change. The answers above provide some code which is worth reading at this point.

Polymorphism and SOLID Principles

Re: @TimoHuovinen comments - the concept of loose coupling goes hand-in-hand with the concepts of polymorphism. If you grasp the basic analogy of a shirt/car parts, then you will be ready to make sense of polymorphism. The best way, at this point is to read the code samples provided by my estimable colleagues in the other answers on this thread. If I say anymore you might get overloaded with too much info.

Picture Attribution.