Cohesion and coupling, what are they? And why is one good and the other bad?

Coupling and Cohesion are the two terms which very frequently occur together. Together they talk about the quality a module should have

You might have got this advice n number of times that "cohesion is good and coupling is bad", without actually going into the details as to what they mean and why one of them is bad and why the other one is good. Maybe because the one who is advising is not aware himself of the details and the one who is getting the advice is hesitant enough to ask, or may be they are not able to give good explanation.

So in this post I am trying to give a good explanation on both, and hopefully good examples which you can co-relate with incidents and things in your daily life.

As usual, lets start with checking what Wikipedia has to say on this

• On Coupling

"In software engineering, coupling or dependency is the degree to which each program module relies on each one of the other modules."

• On Cohesion

"Cohesion is a measure of how strongly-related each piece of functionality expressed by the source code of a software module is"

To put things in simpler terms

• COUPLING - simply means relation or link between two things, which is then specified on to software engineering thus it becomes measure of how much a module (package, class, method) relies or is dependent on other modules (package, class, method)
• Lowly coupled would mean that changing something(major) in one module should not affect the other. 
• Highley coupled modules would mean that a change in one module usually forces a ripple effect of changes in other modules. 
• Low coupling means less interdependency, less co-ordination and less information flow
• High coupling means more interdependency, more co-ordination and more information flow
• de-Coupling ensures that the functional implementation is isolated from the rest of the system
• The general way to achieve loose coupling is through well defined interfaces(like done with plug-n-play devices).
• COHESION - literally means completeness/wholeness with it self, thus is terms of software engineering it becomes how complete is the module(package,..) in itself, or in other words how specific is the module in its functionality or how strongly-related or focused the responsibilities of a single module are
• Low cohesion would mean that the module does a great variety of things and is not focused on what it should do. 
• High cohesion would then mean that the class is focused on what it should be doing, i.e. only methods relating to the intention of the class.
• Cohesion partitions your functionality so that it is concise and closest to the data relevant to it

How about taking some examples, to throw some more light on these?

COUPLING

• High(Tight) Coupling :  
• iPods, iPhones are good example in the non programming world.Considering once the battery dies you might as well buy a new iPod because the battery is soldered fixed and won't come loose, thus making replacing very expensive. A loosely coupled player/phone would allow effortlessly changing the battery.
• You and your wife. :) . You and your wife are very very tightly coupled. If one's nature gets bad, the whole family gets affected and disrupted. And ofcourse, just for example's sake,  replacing/altering one of the module(you or your wife) is out of question, or something more than just expensive 
• A Jigsaw puzzle has pieces that are TIGHTLY coupled. You can’t take a piece from one jigsaw puzzle (system) and snap it into a different puzzle, because the system (puzzle) is very dependent on the very specific pieces that were built specific to that particular “design”.
•  Loose Coupling :
• You and the cashier at the departmental store You communicate through a well-defined protocol to achieve your respective goals - you pay money, he lets you walk out with the grocery. Either one of you can be replaced without disrupting the system.
• Computers in a network are considered loose-coupled systems as a client machine may request data from the server, but the two systems also work independently of each other. 
• Legos, the toys that SNAP together can be considered loosely coupled because you can just snap the pieces together and build whatever system you want to.

COHESION

• Low Cohesion:
• The supermarkets You go there for everything from gas to milk to ATM banking. Products and services have little in common, and the convenience of having them all in one place may not be enough to offset the resulting increase in cost and decrease in quality
• High Cohesion:
• The cheese store. They sell cheese. Nothing else. Can't beat them when it comes to cheese though. 
• A team with non overlapping and well defined roles. Every team member doing his own work but the combination of all that work would create good quality product

Thats it for now. I hope the difference would be more clear after reading this small post, with some real world examples to explain.
And also hope that you all now understand why cohesion is good and coupling is bad :)

Soon I will be putting some design examples of both types of Coupling and Cohesion, to make the difference and details clear design-wise


Good Luck,
Sandeep Rajoria

P.S. - And don't forget to check my Analytics app here