Skip to main content

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
Labels:
Location: Bangalore, Karnataka, India

Comments

Post a Comment

Popular posts from this blog

Multi Tenancy with Codeigniter

In this post I will show you how I converted my normal Codeigniter application into a multi-tenant system.(first step to a SaaS implementation) Note - This implementation is a separate DB multi-tenancy implementation. Lets say we have an up and running CI application name ci_app , with the directory structure like this ./application ./application/config ./application/...so many other important directories ./asset ./asset/js ./asset/images ./asset/css ./system ./index.php which is accessed through browser like http://localhost/ci_app So to implement the multi-tenant arch we are most concerned about the following files, and we will be editing them ./index.php ./application/config/config.php ./application/config/database.php And also we need to create a few new ones Create a tenant folder in your www root directory, lets say tenant_1 Cut the ./index.php from ci_app and paste it in tenant_1 directory  Create a blank file config.php in tenant_1 directory ...
17 comments
Read more

Profiling and checking PHP error_reporting in a Codeigniter App, without editing the config!!

Hi all, You must have definitely used the Profiling in Codeigniter and error_reporting many a times in Development and Testing environment, but I am sure you must have missed it on a real Production environment. As there are scenarios, where you want to quickly debug the Production application and find out what PHP errors is the application throwing, check the page profile, that too without putting the time and effort in replicating the whole production environment on your local machine, or perhaps a testing server. This small piece of code(we could perhaps call it a hack), which I have used in almost all of my CI applications, will make your life very easy, without losing anything on the security of the system. Following points, essentially sum up what exactly it does - Check for the dev(or root or admin, whichever name you use for the su access), if it is logged in, as we don't want others to see all the Profile data and other errors. Check for a specific query str...
5 comments
Read more

How I solved design problems by using various design patterns in my Laravel Project

Hey guys, Lately I have been working on a Virtual marketplace application using Laravel and PostgreSQL. So, when I was asked to build this huge application, the biggest challenge I faced was the design. Having a fair bit of prior experience in Laravel and upon following the current community trend, I decided to go with Laravel. And I hoped and expected that this, somewhat opinionated framework, would take care of my design to a large extent. When I actually started designing it, I realized that for a small/medium application Laravel already has things in place, you, as a developer just need to follow the guidelines set in place by the framework and use the features its providing out-of-box. However, for a larger application, with lot of interdependent modules and complex business flows, you need to make your own design decisions as well along with the existing features. This gave me an opportunity to take a look into the various existing design patterns to solve my design probl...
4 comments
Read more