Application development is composed of many interconnected parts which interact with each other. To withstand high market demand and increasing competition, software should have a good look and feel, and ease of use. To develop a compatible solution, the developer has to think about compound structure as well as user perspective. It's quite difficult to develop such a product single-handed. It's teamwork, where the development is running alongside. The team members will build up separate small modules dedicated to part of the actual solution. These small modules will be clubbed together and interact with each other to form a complete solution.
Each module which has been developed will be performing a unique responsibility. When a module is responsible for a single task, it will be called cohesive. The cohesiveness will make the module more maintainable. Also, it will be less frequently changed. A good design perspective is to try writing a module which will be highly cohesive.
The two modules developed separately will now need to have interaction. To make them interactive, we have to introduce them. This will be done by making them dependent on each other. This dependency is termed coupling. When the code size and number of modules are small, coupling won't be a problem. But in an enterprise application, the code size is huge. Any little change makes a difference and then all of its dependencies should be changed accordingly at a number of places. This makes the code unmanageable. So it's always recommended to have loosely coupled modules.
Let's take the example of a desktop, the one which we use in our routine. A desktop consists of a monitor, CPU, keyboard, and mouse. If a new monitor with some advanced features is introduced in the market, what we will do? Will we buy a new desktop or just replace the monitor?
As per the convenience and also the cost, it's feasible to just replace the monitor and not the whole desktop; how come this is possible? It's possible because the desktop is assembled with subunits, which are easily replaceable. Each subunit is cohesive for the work and they are not tightly coupled. This happens when we use modularization. When we write an application that uses similar concepts, it is called modular programming.