Object-Oriented – Difference Between Encapsulation and High Cohesion

Cohesion refers to the degree that elements of a module belong together. The more cohesive a module is, relative to other modules in the software, the more independently it can operate. Encapsulation is one of the techniques by which cohesion can be achieved. While encapsulation is certainly an important element of cohesion, cohesion also addresses other concerns that affect cohesion.

The degree in which components depend on each other for their proper operation is called coupling. Coupling is achieved primarily by the mechanisms chosen to interact between components. The less coupled a system is, the more cohesive it is. Hence, low coupling is a desirable feature.

Let's explore a few examples of relationships between components, in order of increasing cohesivity:

Inheritance
Inheritance is very tightly-coupled, and therefore has relatively low cohesivity; if you break the inheritance, you break the program. But inheritance is desirable for systems where you want and need that kind of tight coupling, because you want the components to work closely together. It is used quite effectively in Graphical User Interfaces, for example.

Composition
Composition is less tightly-coupled than Inheritance; you can replace a local object in a class with a different implementation without breaking an inheritance chain. But you still have to change the class's internal implementation; it's just that the changes are confined to a single class.

Composition with interfaces
Here, the class is only dependent on an Interface. Consequently, you can change out the implementation without changing the class at all, provided the implementing class conforms to the specified interface. You can even change out the implementation of the interface at runtime, by handing an instance of the desired class to the constructor of your class.

Data Transfer Objects and View Models
This technique allows you to create classes that serve as data containers, without any behavior associated with them. Now, the modules between which you are communicating don't need to know anything about each other at all, not even a common interface. All they need to know about is the DTO or View Model object. But things are beginning to become a bit more complicated, because now you're spending a lot of time mapping fields to other fields and copying data between different structures.

Streams, strings and pipes
With strings and streams, you take advantage of a well-known mechanism to communicate between modules. This arrangement is the most loosely-coupled, because the module doesn't have any dependencies at all, except for widely-available, cross-platform compatible primitive data structures. Strings are the most ubiquitous of all data types; examples of their use in an API include database connection strings and communication protocols that use strings or binary arrays to transmit data. The disadvantage of this mechanism is that you now need a parser, a serializer, or some similar mechanism in your modules to translate the raw data being transmitted between modules into a usable form.

As you can see, high cohesivity isn't a perfect ideal, nor is it universally desirable. As with many other things in computing, it is a tradeoff between competing objectives.