Problem Definition

Cohesion and coupling are concepts that are reasonably easy to understand, but nonetheless, it is worthwhile to gather readable illustrations of where they apply. Browse the hundreds of Web pages that attempt to explain these concepts, picking your favorite examples. Categorize these examples, so that the reader will see the big picture, rather than just a set of redundant illustrations. Many of these pages mention related concepts; list some of them and explain how they relate to cohesion and coupling.

Introduction
Cohesion and Coupling are two cornerstones of Object-Oriented Programming. They sound similar, but have very different meanings. Cohesion is the act or state of sticking together or the logical agreement". It is the basic idea that a class has a focused set of responsibilities or behaviors from a particular perspective. In contrast to cohesion, Coupling refers to the physical connections between elements of the OO design (eg: the number of collaborations between classes or the number of messages passed between objects) within an OO system. In a simple way, it gives the measure of the interdependence of one module to another.

Cohesion
Cohesion is the "glue" that holds a module together. It can be thought of as the type of association among the component elements of a module. Cohesion is related to the Single Responsibility Principle. Generally, one wants the highest level of cohesion possible. An object with high cohesion is defined for one purpose and it performs only that purpose. An object with low cohesion tends to try to do a lot of different things. For example, if there is a Card object which is responsible for drawing itself, sending messages back to the server, and also executing game logic then it has low cohesion because that one class is attempting to do too much. A system can also have low cohesion if too many objects are attempting to do the same thing. For example, if a system has objects to implement a NetRunner game and every card has a unique class with a rendering method and that method is nearly identical in all classes, then the system has low cohesion. A good software design is always designed to achieve high cohesion.

Types of Cohesion [2]

1. Coincidental cohesion (worst)- A module has coincidental cohesion if its elements have no meaningful relationship to one another. It is explained with an example here [3]. 2. Logical cohesion- A module has Logical cohesion when parts of a module are grouped together as they are logically categorized to do the same thing, even if they are different by nature (e.g. grouping all I/O handling routines). Diagram 3. Temporal cohesion- A temporally cohesive module is one whose elements are functions that are related in time. That is operations that are performed to reflect a specific behavior or state. It is explained with an example here [4]. 4. Procedural cohesion-A procedurally cohesive module is one whose elements are involved in different activities, but the activities are sequential.Diagram 5. Communicational cohesion- A communicationally cohesive module is one whose elements perform different functions, but each function references the same input information or output.Diagram 6. Sequential cohesion- A sequentially cohesive module is one whose functions are related such that output data from one function serves as input data to the next function. The intent is to implement a sequence of operations Diagram. 7. Functional cohesion (best)- A functionally cohesive module is one in which all of the elements in a module performs one and only one computation and then returns a result. Object-oriented languages tend to support this level of cohesion better than earlier languages do. Studies indicate that the first two types of cohesion are inferior, communicational and sequential cohesion are very good and functional cohesion is superior. A detailed description of each cohesion type is given here [5].

Advantages of high cohesion

Cohesion is the idea that a given thing (be it a system, and object,or a method) does a single, clearly definable thing. This has the benefit of making your code easier to follow. Promotes code reuse, since small atomic blocks are easier to reuse then larger blocks. High cohesion makes it easier to replace a module by another one that provides same functionality. High cohesion reduces complexity of the system, and hence increase the application's reliability. If the module is highly cohesive, the software is more readable and maintainable. Communication between developers is easier.

Coupling
Coupling is a qualitative measure of the degree to which the classes, modules or subsystems are connected to one another. It can be defined as the amount of interaction of one object with another object, or one module with another module. For a good software design, it is always advisable to minimize coupling. Low coupling does not mean no coupling, the goal is reduction rather than elimination of coupling. A system with no coupling is, by definition, not a system. Low coupling indicates that each object or module performs independent tasks. In general, low coupling can be well explained by Law of demeter. It states that classes within a module or subsystem should have only limited knowledge of classes in other modules or subsystems. In simple terms, 'Law of Demeter' says "Each unit should only talk to its friends; don't talk to strangers". Strong coupling means that one object or module is dependent on other object or module to perform an operation or task. It simply means that the object or module is strongly coupled with the implementation details of another object or module. With low coupling, a change in one module will not require a change in the implementation of another module.

Types of Coupling [7]

1. No Direct Coupling (low) - These are independent modules and so are not really components of a single system. 2. Data Coupling - Two modules are data coupled if they communicate by passing parameters or data arguments. Increase in data coupling results in increased complexity of interfaces, because the bandwidth of communication between classes increase Diagram. 3. Stamp Coupling - Two modules are stamp coupled if they communicate via a passed data structure that contains more information than necessary for them to perform their functions. For example, class B is declared as atype for an argument of an operation of class A. Therefore, modifying the system could be complicated as now class B is a part of the definition of class A. Diagram 4. Control Coupling - Two modules are control coupled if they communicate using at least one "control flag". For example, operation X() invokes operation Y() and passes control flag to Y. In this case, changing code of operation Y may require change in flag value passed by X. Diagram. 5. Common Coupling - Two modules are common coupled if they both share the same global data area. It is useful to establish values that are common to entire application, however, it can lead to uncontrolled error propagation that can be difficult to trace. Diagram 6. Content coupling (high)- Content coupling is when one module modifies or relies on the internal workings of another module (e.g. accessing local data of another module). Therefore changing the way the second module produces data (location, type, timing) will lead to changing the dependent module. This violates information hiding - a basic object oriented design concept. In object-oriented programming, Subclass coupling describes a special type of coupling between a parent class and its child. It describes the relationship between a class and its parent. The class is connected to its parent, but the parent isn't connected to the child.

To achieve low coupling

1. Strive for low message coupling. It can be achieved in the following ways -

Number of messages passed between objects can be reduced. Messages can be simplified using few parameters. Avoid requiring multi-message sequences.

2. Strive for low association coupling. It can be achieved by -

Reduce extent to which objects depend on the internal structure of each other. Reduce the use of superclasses instance variables by subclasses (strong form of the Law of Demeter).

3. Strive for moderate inheritance coupling. It can be achieved in the following ways -

Abstract so that subclasses depend on the methods (but not the structure!) of their superclasses. Use or refine as many of superclass' operations as possible in the child classes.

Disadvantages of high coupling

Decreases the flexibility of the application software. Developers / maintenance programmers need to understand potentially the whole system to be able to safely modify a single component. Object interaction complexity associated with coupling can lead to increased error generation during development. Decreases the scalability of the application software. Changing requirements in one part of software will potentially require wide ranging changes in the entire application. Decreases the maintainability of the application software. More thought need to go into choices at the beginning of the lifetime of a software system in order to attempt to predict the long term requirements of the system because changes are more expensive. Testability is likely to degrade with a more highly coupled system of objects.

Cohesion and Coupling Examples

As the popular proverb says " A picture is worth a thousand words ", we will try to represent cohesion and coupling in terms of visual programming metaphors. Observe Figures 1 and 2. What can one say about the two diagrams? Which one is easy to understand, remember and modify? Obviously the answer would be Figure 1. This is exactly why it is recommended to have high cohesion and loose coupling in design or implementation of a software application. The two figures gives a clear visualization of the underlying concepts of coupling and cohesion. . In General Let us take a look at some simple real life examples to understand the relation between these two terms. Example 1. Project team - If we assume that a certain project has 20 people working on it, the possible communication channels would be around 400. The team would be very inefficient with high communication overhead. It can be viewed as an example of tight coupling. Therefore, in any team, certain roles and responsibilities are formally assigned to team member, to enhance productivity of the team with smooth coordination. Well defined roles of a team member can be viewed as high cohesion, and establishing communication channels (like defining hierarchy or reporting structure) can be viewed as low coupling. This is a very practical example of low coupling and high cohesion comes. Example 2. Car - Let us consider another real life example of a car. It has the engine, tire, steering wheel, gear box, brakes etc. Each component of the car performs a given set of functions. Therefore, if the car breaks down, the problem can be analyzed and only certain part needs to be repaired. This can be considered as high cohesion, as each component focuses on the assigned task. At the same time, in order drive the car, all these parts need to interact with each other. This can be viewed as coupling. Example 3. Child and Parent relationship - Cohesion and coupling can be well expressed using the analogy of a parent child relationship. The child inherits characteristics of its parents. This can be viewed as coupling. At the same time, there is no coupling in the siblings. In Object Oriented terms Polymorphism and encapsulation are two major design principles of object oriented programming. In object oriented terms, we can say that, the main vehicle of coupling is polymorphism [8] and the main vehicle of cohesion is encapsulation. More explanation is provided in cohesion and coupling. In order to achieve modularity, we need to have low coupling and high cohesion.Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules. Booch 1994 Principle: Modularity = Low Coupling + High Cohesion

It can be simply understood as, breaking something complex into set of manageable pieces. Consider the example of order processing system. If we decide to write entire software in only one program, it will become lengthy, unmanageable, complicated and hard to debug. Instead, we can divide it into modules or subsystems like order entry, order processing, billing and complaints. [edit]

Conclusion
Code that is easy to maintain and reusable can be attained by sticking to loose coupling and high cohesion in objects. The concept of coupling is usually related to the concept of cohesion so low coupling facilitates high cohesion, and vice versa. It is difficult to obtain perfect high cohesion and low coupling throughout the program. Once all the unitary functions that depend only on their inputs are written, a bit of less cohesive and more coupled code is required to glue them together into a working program. But, there are also times where tight coupling is desirable. Tighter the coupling, it improves performance as it reduces the cost of interfaces. So, tight coupling is important when one process is very stable and wants maximum performance and loose coupling comes into play when flexibility is required rather than stability. There can also be situations where even though high cohesion is attained, tight coupling is also present. This means though it may be logically laid out, it's tough to change because of tight interdependencies which is pretty bad. The other kind of bad software is eventhough the module is loosely coupled but it may lack cohesion. That means that there are few explicit interdependencies between modules, but none of the modules are necessarily authoritative about any particular aspect of the system. This in turn results in a scattergun approach to ongoing system evolution as even minor changes ripple through multiple components or systems. As to conclude, the objective of a good software should be to achieve high cohesion and low coupling.