Coupling and Cohesion in Software and Business

One of the important topics in Object Oriented Programming that is often overlooked or not even considered is that of Coupling and Cohesion. A sound understanding of these concepts can make a huge difference in how you package functionality within your program and how flexible your program can become for enhancements.

When performing source code review, keep coupling and cohesion in mind and ensure that the classes within a package all perform same or closely related activities (high cohesion) and that classes within different packages don't refer each other too much or at least in a well-defined manner (low coupling).

Definitions


Coupling is how inter-dependent two functional components are within your program. High coupling is bad, because if you change one function, you might end up affecting all the dependent functions as well.

Cohesion is how closely the parts within a function work together to make the function as one single, well-defined unit. High cohesion is good, since you can treat the whole function as a black box, thereby abstracting your system for better clarity.

Coupling Types

Type (worst to best)	Description
Content/Pathological Coupling	When a module uses/alters data in another
Control Coupling	2 modules communicating with a control flag (first tells second what to do via flag)
Common/Global-data Coupling	2 modules communicating via global data
Stamp/Data-structure Coupling	Communicating via a data structure passed as a parameter. The data structure holds more information than the recipient needs.
Data Coupling	Communicating via parameter passing. The parameters passed are only those that the recipient needs. No data coupling : independent modules.

Cohesion Types

Type (worst to best)	Description
Coincidental Cohesion	Module elements are unrelated
Logical Cohesion	Elements perform similar activities as selected from outside module, i.e. by a flag that selects operation to perform. That is, body of function is one huge if-else/ switch on operation flag
Temporal Cohesion	Operations related only by general time performed
Procedural Cohesion	Elements involved in different but sequential activities, each on different data (usually could be trivially split into multiple modules along linear sequence boundaries)
Communicational Cohesion	Unrelated operations except need same data or input
Sequential Cohesion	Operations on same data in significant order; output from one function is input to next (pipeline)
Informational Cohesion	A module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure. Essentially an implementation of an abstract data type
Functional Cohesion	All elements contribute to a single, well-defined task, i.e. a function that performs exactly one operation

Tweaking thought-less designs

Bad design usually sticks like a sore thumb. By design, I am not talking about IT-centric designs such as user interfaces for Blackberry, iPhone, etc. I am talking about design that is a part of what we interact with in our everyday lives - beds, sofas, doors, streets, and so on. Every element that we interact was designed by someone, for good for bad. Bad designs are easy to find, such as narrow streets, buildings with only one exit, etc.

However, design that is not so bad but at the same time could be better is not easy to find. It is more like an irritant. We know that something is wrong, but we can't quite place it. It may gnaw our minds for the few minutes before and after we interact with it and goes away till we interact with the same piece again. Recently, I came across such a design that prompted me to write this post. Now, I am not really ranting about the design (although blogs are rants in most cases). Instead, I am posting this to see if any of you who come over here have experienced such nagging as well and hopefully knowing that the nag has a reason may help you be more at peach - a noble goal indeed!

The design in question is simple - a restroom. Rather, the sign to a restroom. The picture below is the corridor in my office building that I rarely visit. By looking at it (the viewpoint from when you get into the corridor), can you figure out where the restroom is?

I had the same issue. While thankfully I was not in a hurry to reach the said destination, it did take me a wrong turn and some careful looking on either side to find the right place (the different gender rooms are on either side of the entrance).  Of course, there is a nice little universal sign in front of the door that indicates my destination. However, I could not see it until I was right in front of the door.

While this design is in general adequate and acceptable, it could have been made a lot better with just a simple tweak - make the sign perpendicular to the door so that it sticks out in the corridor (probably near the ceiling so that it does not hit someone in the face). This way, it will be fairly easy for someone to know where the restroom is without having to look at each and every door! It does not really cost much to make this change, but can make a difference in simple comfort.

Another example I have seen is the way doors swing in a cafeteria. For example, it's probably more useful to set up the doors such that you push when getting out of the cafeteria and pull when you are going in. This way, if you have your hands full with food, you just push the door. However, I have seen this being done the other way.

I am sure if we look into the software we write or use everyday, such simple to fix issues can be found in many places that only required a little extra effort to make a difference. Some good books to read in this regard are The Universal Principles of Design and The Design of Everyday Things. Hopefully it helps in increasing your attention to detail. It definitely helped for me.

Can you think of such minor annoyances for which you could see some simple fixes that would make just the difference required? Please post a comment.