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)?

3 Answers 3


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.

  • 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
    Commented Oct 3, 2012 at 7:05

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.


My personal opinion is that logical term was choose badly and leads to confusion. We tend to think that logical is good. In many scenarios functional can be interchanged with logical.

I would replace logical with technical term because your focus on technical part rather than on (and I want to use word logical here but it'll be misleading in the context of this discussion) what this component does for whole system.

A typical example can be grouping of classes that provide endpoints for some API.
If you group them in some folder because they provide endpoints it's a technical cohesion. If you group them because they provide some functionality (like management user list, for example) it's a functional cohesion

Moreover, I also would challenge functional term here because it's too broad. It can refer function as syntax construction as well as functionality of a thing. In above example an endpoint class has 2 functionalities: endpoint and business logic.

I would replace functional to logical. It refers to business logic, it refers to logical view of 4+1 software view model and, generally, we have a tendency to call things "logical" when they're right.