Playing Strong and Loose

There are four important concepts in development, sometimes they get mixed up but its important to have a good understanding of the relationship between them.

"Abstraction leads to loose coupling"

"Encapsulation leads to strong cohesion"

So why exactly are these statements so important are why do we sometimes get them confused?

Abstracting Away the Detail

The purpose of abstraction is to hide detail.

Detail leads to complexity, complexity leads to instability and instability leads to unhappy users.

Whenever we define how pieces of code are going to interact this should be based on an abstraction that represents the functionality that is going to be consumed, it shouldn't be based on details of how that functionality will be implemented.

As a slightly contrived example, if you wanted to save files you wouldn't expect the interface to do so to talk in terms of disk sectors and binary sequences. You might instead expect to use file and file-writer abstractions to protect you from that complication.

Once your protected from the detail then the implementation can be tweaked, modified or completely rewritten without your code breaking, this is what we mean by loose coupling.

Coupling is a mechanism by which classes are connected to each other and can act as a channel for all sorts of things to be transmitted between them including complexity, defects and breaking changes.

Encapsulate the Concept

A class in your code should represent something in your problem domain, anyone that understands that domain should recognise what the class represents and realise how it can be used.

When this isn't the case and a class only loosely represents a concept developers will end up having head scratching moments where they have to write code where it isn't immediately obvious either why some invisible join between classes has to be made or why a certain piece of functionality lies in a particular place.

Classes that do properly represent a concept are said to have strong cohesion, every line of code in them is all geared towards representing the same concept.

Cohesion is a mechanism by which understanding can be transmitted to a developer looking at your code leading to less head scratching and more productive time building well engineered solutions.

Strong and Loose

Sometime these concepts can get mixed up in developers minds, this isn't surprising since they very often interrelate, a class that operates at a good level of abstraction often also demonstrates good encapsulation.

A good abstraction hides the detail of the implementation by being well focused on representing a single concept within the system which brings us back to encapsulation.

The important thing to remember is that its all about the relationship between code, code inside a class should be very closely related whereas the code between classes should be very loosely related.

If code represents detail this means detail in one class shouldn't relate to or depend on detail in another class, if it does its because an inadequate level of abstraction is failing to hide detail or because bad encapsulation means code that should be together has been split-up.

Spotting which once of these is causing the problem is not always easy and in many ways is the essence of what it means to be an experienced developer but remembering that all these things are interrelated and that detail, complexity and confusion are the enemy is a pretty good start.