Take the 2-minute tour ×

From the c2wiki page on coupling & cohesion:

Cohesion (interdependency within module) strength/level names : (from worse to better, high cohesion is good)

  • Coincidental Cohesion : (Worst) 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 (see also CommandObject). i.e. body of function is one huge if-else/switch on operation flag
  • Temporal Cohesion : operations related only by general time performed (i.e. initialization() or FatalErrorShutdown?())
  • 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. i.e. define structure of sales_region_table and its operators: init_table(), update_table(), print_table()
  • Functional Cohesion : all elements contribute to a single, well-defined task, i.e. a function that performs exactly one operation get_engine_temperature(), add_sales_tax()

(emphasis mine).

I don't fully understand the definition of logical cohesion. My questions are:

  • what is logical cohesion?
  • Why does it get such a bad rap (2nd worst kind of cohesion)?
share|improve this question
add comment

2 Answers

Logical cohesion can be bad because you end up grouping functionality by technical characteristics rather than functional characteristics. For example, consider an application consisting of multiple modules. Each module represents some business domain and has corresponding data access code. If you group all data access code across all modules then you have logical cohesion. After all, it is all data access and it in some cases it is beneficial to be able to evaluate the data access patterns of an application. This however is problematic because the business domain provides the module boundaries, not the technical domain. By achieving logical cohesion you end up losing on functional cohesion. Typically, the business domain defines a well-defined unit of deployment and technical aspects are there to support the business domain.

share|improve this answer
That's a good answer, although to avoid confusion, I'd mention that in the context of object oriented programming (and the examples on Wikipedia and c2wiki), a module is essentially a class. This means that the comment about the "huge if/else" also makes more sense. –  Daniel B Oct 3 '12 at 7:05
add comment

From how it is described, I would say it is about coupling code together that has some cohesion, but breaks object orientation.

Example: calculation of a polygon's area. When you put the calculation for the square together with the calculation for the triangle, and only choose by the input-param, then you have grouped two things logically by their outcome, not taking into account their real nature.

share|improve this answer
add comment

Your Answer


