Irrespective of programming language, cohesion and coupling form the solid basis of organizing fresh code and refactoring bad code.

These commonly forgotten principles of software engineering are crucial to develop, maintain & learn industry strength programming.

Lets take a look, Cohesion is defined as the way functions, classes & the services are related together to deliver their intent.

We have 5 types of cohesion.

• Functional cohesion: This is the most desirable type of cohesion. If you state that a C++ service is in functional cohesion, it implies that the classes that make up the service and functions that make up those classes are also in functional cohesion. Functional cohesion is nothing but single responsibility principle. The code does nothing else but execute a single desired intent. There is no random line of code within it with a different intent.

• Sequential cohesion: This means an algorithm is executed in a series of steps or series of functions. You can number the intent of your function.

i.) f(T)

ii.) g(R)

iii.) h(S)

• Communication cohesion: If you lay out your functions by passing the result of one to the next, by basically communicating data.

f(T)-> R

g(R)-> S

h(S)

• Temporal cohesion: Sometimes you may need to execute lines of code on a one time basis, setting up a cache/lookup/timer, creating a database connection/socket, logs/alerts. This is temporal cohesion.

Sequential, Communication & Temporal cohesion combine to form a functionally cohesive code.

FUNCTIONAL ~= (SEQUENTIAL code(1..n) + COMMUNICATION code + TEMPORAL code ) (in all combinations)

• Procedural cohesion: This is a "to be" avoided cohesion. The code contains a lot of random functions grouped together and the true intent is not always single or recognizable. Its not easy to identify this in legacy code, you could mistake a set of sequential code or communicating code to belong to functional cohesion, but the caller of the function may be in procedural cohesion. It is easier when you analyze the code by beginning at the service interface level and branch out using a commercial code analyzer. At any point if the line of code is not in [SEQUENTIAL, COMMUNICATION, TEMPORAL] step with the previous line, you may have a cohesion issue.

Ask the question - Is this line of code the logical next step of the algorithm (Sequential) ?, Do we have the previous line communicating something as a result to this line (Communication) ? or Is this part of a required Temporal execution that the functionality cannot do without.?

If you are updating legacy code, whether it is business logic or a game, the next line of code you plan to write has to be the one which makes the most functionally cohesive sense.

If cohesion helps in finding the best way to group code, coupling helps in analyzing dependencies i.e. function calls, service calls.

We have 4 types of Coupling,

• Data coupling: This is the only desirable type of coupling. Function/service calls another function/service passing data. All the data passed is required in the called function. It is processed and a result may or may not be returned depending on the type of function. In case of a service a response is sent.
• Stamp Coupling: A function called with several data parameters but at called site only a partial set of the data is required - it becomes a huge maintenance nightmare. This is to be avoided, common problems include - a naive programmer during maintenance accidentally changes a parameter that need not be referred to in the execution.
• Control coupling: When you control function(s) using Boolean variables it results in a huge chain of functions/services coupled by (true/false) and code laid out with if/else blocks. This is quite ineffective in industry code, as fresh requirements come in, you may need more than one logic circuit to be executed, and you need to change the function signature to accommodate the new variable-parameter. This will happen every now and then and soon you will have an unmaintainable function signature with say, 50 parameters. Service interface changes for a new parameter is even more complicated as it breaks at enterprise level. Control coupling is the bane of all C++/Java service code in major legacy code-bases. A better option for service level control is to store application state in a database.
• Common coupling: When functions share global data the functions are common coupled. There is still legacy code with file scope or class scope common coupled functions.

Stick to Data coupling as far as possible.