Tag: structured design

Stretch out for your cohesion

Today I have something of a warm-up. A few simple exercises that can help you define the type of cohesion that a class has. In Structured Design (for more details about the article itself go to the A brief history of coupling and cohesion post) the authors proposed a simple technique, which was to describe a module’s (class in our case) function in a single sentence. 

So now let’s look into their guidelines:

1. “If the module is functional in nature, it should be possible to describe its operation fully in an imperative sentence of simple structure, usually with a single transitive verb and a specific non-plural object.”

For example:

  • Calculate VAT
  • Calculate commission
  • Read the temperature
  • Retrieve the order info

2. “If the only reasonable way of describing the module’s operation is a compound sentence, or a sentence containing a comma, or a sentence containing more than one verb, then the module is probably less than functional. It may be sequential, communicational, or logical in terms of cohesion.” 

For example:

  • Update time spent on the task, employee’s work time, and invoice based on time card. – probably communicational cohesion, as all elements are communicationally connected by a time card. 
  • Update the order and save it. – sequential cohesion.

3. “If the descriptive sentence contains such time-oriented words as “first,” “next,” “after,” “then,” “start,” “step,” “when,” “until,” or “for all,” then the module probably has temporal or procedural cohesion; sometimes but less often, such words are indicative of sequential cohesion”

For example:

  • Before sorting, save data, remove duplicates, and check checksums – temporal cohesion as we assume that order is not essential here.
  • Download exchange rates, next send sales results to the sales department and new orders to the orders department. – probably procedural cohesion as we model the following steps where order is essential but output data of elements is not input data of those following them, so it’s not sequential.

4. “If the predicate of the descriptive sentence does not contain a single specific objective following the verb, the module is probably logically cohesive. Thus, a functional module might be described by “Process a GLOP.” A logically bound module might be described by “Process all GLOPS,” or “Do things with GLOPS.””

5. “Words such as “initialize,” “clean-up,” and “housekeeping” in the descriptive sentence imply temporal cohesion.”

Those guidelines might be considered too general, but in my opinion it is an excellent exercise sometimes to ask ourselves “what does that class actually do?”. 

What about a situation when we are considering adding a new element into an existing class? In Structured Design (the book), the authors give us a similar technique based on the principle of association. This time we should answer the question “why does the element fit there?”. As a result, we could end up with the following statements:

1. “Z is associated with this module containing X and Y, because X, Y and Z are all related by virtue of having the ‘glop’ property”

2. “It’s OK to put Z into the same module as X and Y, cause they’ are all related in such-and-such a manner”

3. “It’s OK to put Z into the same module as X and Y, cause they’re all members of the glop set.”

Last but not least, a hint from me: model problems/features in a group. Why? Since the bigger our understanding of the problem, the higher the cohesion is. However, there is a tiny catch here. Each of us analyzing a problem has their own version of it in mind and the same goes for solutions to it. That’s why it is so important to share this process with others. Through sharing, we build a common understanding of the problem within the team.

P.S. If you have enjoyed this article and would like to always have it with you offline or you would like to have some super sketch notes with types of coupling and cohesion to print out and stick them above your bed, don’t hesitate and download an ebook, that I have for you. You will find there a few great posts about rotting design, coupling and cohesion put together into PDF, EPUB and MOBI formats.

* indicates required
Photo by kike vega on Unsplash

A brief history of coupling and cohesion

From the very first time when coupling and cohesion were defined, there was one issue with both of them. Let me ask you a few questions:

– how can I recognize that one class is tightly coupled with another?

– how can I verify whether or not a specific class is cohesive?

Well, my class is definitely highly cohesive and loosely coupled with others, but a class of my colleague’s… hmmm… he or she had better reconsider their future career as a developer.

It turns out that each of us can have different images of what is loosely/tightly coupled and what is or is not cohesive. What is most interesting, any of us can be right. Why is that so? Both concepts are highly abstract. How do we deal as human beings with such concepts? We look for analogies to our daily lives. You can quickly validate this by looking into the most highly rated answers to general questions about coupling and cohesion on Stack Overflow. You will find a ton of analogies. Just take a look:

– “Car and Spare parts analogy of coupling”

– “You and the guy at the convenience store.” – loose coupling

– “The cheese store.” – high cohesion

– “You and your wife.” – tight coupling

Analogies are great, and we like them. They help us to get the context and shed some more light on the problem. But do they really explain everything? I don’t think so. Ok, so now it’s time to dig into Wikipedia or any other pedia. What we see there are some classical definitions that I more or less included earlier in this article. Then we scroll a bit down, and we notice something more as there are types of coupling and types of cohesion. No one told us about them, so let’s take a look at what more your search engine of choice returned. So now is the moment when real fun begins. There are a lot of publications and books. One author says that, for example, there are only two types of coupling, another says there are twelve. Someone else that all the others are wrong because they didn’t consider this and that. At the same time, some of the publications even use different names; for example, cohesion is sometimes referred to as “functional binding” or “strength”. 

When did it all begin?

To answer this question, we need to go back in time to 1974, when Larry Constantine, Glenford Myers, and Wayne Stevens published in IBM Systems Journal their article called Structured Design. They described coupling and cohesion there, but actually, Larry Constantine is considered to be the father of these concepts.

One year later, the book Reliable Software Through Composite Design by Glenford Myers was published. Quite a big part of it was dedicated to both concepts. On a side note, I can say that it’s a great book; it’s written in an accessible way, and the most fascinating thing about it is that while reading it you can have an impression that in the last 50 years little has actually changed when it comes to the challenges in software design and its modularity.

Then after another few years, Larry Constantine and Edward Yourdon published their book called Structured Design – the same as the article from 1974. They were also referencing Mayers’ book, which goes to show that those guys for few years were doing a lot of research in the area of coupling and cohesion.

We could probably say now that those were the 70s, so it should be quite outdated now. Procedural programming was standard back then, they had modules, and now we do OOP, we have our cool, shiny classes. Why should we even care?  Well, it turns out that even though paradigms have changed, coupling as well as cohesion are still with us and they feel pretty fine in OOP. When in the early 90s Timothy Budd published his book An Introduction to Object-Oriented Programming you could find there that counterparts of modules in OOP are classes. Personally, I would go further and say that both concepts are so universal, that I can easily imagine, for example, a loose/tight coupling between packages in Java or even between microservices.

I hope that I have sparked off your curiosity and you would like to know more about both concepts as well as their above-mentioned types :). Don’t wait and go here to read more about coupling or here about cohesion.

P.S. If you have enjoyed this article and would like to always have it with you offline or you would like to have some super sketch notes with types of coupling and cohesion to print out and stick them above your bed, don’t hesitate and download an ebook, that I have for you. You will find there a few great posts about rotting design, coupling and cohesion put together into PDF, EPUB and MOBI formats.

* indicates required