Cohesion of a single module/component is the degree to which its responsibilities form a meaningful unit; higher cohesion is better.
Coupling between modules/components is their degree of mutual interdependence; lower coupling is better.
- Size: number of connections between routines.
- Intimacy: the directness of the connection between routines.
- Visibility: the prominence of the connection between routines.
- Flexibility: the ease of changing the connections between routines.
A first-order principle of software architecture is to increase cohesion and reduce coupling.
Additional information can be found at the link I added below.
Coupling and cohesion are often used as opposite ends of a scale in measuring how "good" a piece of software is. They are very common metrics for measuring the quality of object-oriented code.
Cohesion describes how "focused" a piece of software is. A highly-cohesive system is one in which all procedures in a given module work together towards some end goal. High cohesion is often characterized by high readability and maintainability.
Coupling describes how reliant a given piece of software is on other modules. A highly coupled system in one in which the procedures in one module can directly access elements of another module. A low coupled system in one in which the procedures of one module can only interact with the procedures of another through an interface channel. Highly coupled systems are often characterized by code that is difficult to read and maintain (the reason cohesion and coupling are often used as opposites).
If you know what UML diagrams look like, then you can think of a highly coupled system as one in which there are multiple arrows pointing away from and into each module in the diagram.