Software design literature ranks cohesion on a scale from coincidental to functional. Name the main levels of that scale and give an example of a class sitting at a weak level versus a strong one.

## The scale Cohesion was first ranked as an ordinal scale in structured design (Larry Constantine, later Yourdon & Constantine, then Stevens/Myers). It was written for procedural modules but transfers cleanly to classes, packages, and services. From **weakest to strongest**: | Level | Members are grouped because… | Typical smell | |---|---|---| | **Coincidental** | no reason at all | `Utils`, `Helpers`, `Common`, `Misc` | | **Logical** | they fall in the same broad category, and a flag/parameter picks one | `handle(type)` with a giant switch; `IOHelper` doing disk, network and keyboard | | **Temporal** | they run at the same *time* | `Startup`, `Shutdown`, `onAppLaunch` doing ten unrelated inits | | **Procedural** | they run in a fixed *order* | `processMonthEnd()` calling unrelated steps in sequence | | **Communicational** (a.k.a. informational) | they act on the same *data* | a class holding every operation over one record | | **Sequential** | one member's *output* is the next one's *input* | tokenize → parse → evaluate | | **Functional** | they all serve **one single, well-defined task** | `TaxCalculator`, `PasswordHasher`, `CsvRowParser` | Some authors insert **procedural** and **communicational** in the other order, or add a top level for objects that also encapsulate their own state (**object/informational cohesion**). Do not fight over the exact ordering in an interview — what matters is that you can (a) name the weak end, (b) name the strong end, (c) diagnose a real class. ## Why the weak levels are weak — the mechanism - **Coincidental:** nothing predicts what is inside, so nothing predicts where a new thing goes. The bucket grows without bound, and every consumer depends on the whole bucket, creating wide accidental coupling. - **Logical:** the giant `switch`/`if` on a type flag means every new variant edits the same function — the exact shape the Open/Closed Principle and GRASP *Polymorphism* exist to remove. Callers must also pass a magic flag, so the interface leaks the branching. - **Temporal:** "happens at startup" is not a design relationship. When the timing changes (lazy init, feature flags, a new deployment model) the grouping evaporates and you must untangle unrelated code that has meanwhile grown shared state. - **Procedural:** ordering is a fragile reason for togetherness — reorder the workflow and the class's justification disappears. Also common in "transaction script" style code where domain logic drains out of the entities. ## Why the strong levels are strong - **Communicational:** everything works on one data structure, so encapsulation is natural — this is basically what an OO class *is*, and it aligns nicely with GRASP **Information Expert** (give a responsibility to the class that holds the data needed to fulfil it). - **Sequential:** the pipeline shape gives an obvious ordering and obvious seams for testing each stage. - **Functional:** the class is trivially nameable, trivially reusable, trivially testable, and has one reason to change. This is the target and it lines up exactly with the Single Responsibility Principle. ## The modern caveat: data-relatedness is not enough A class can be at communicational level (all methods touch the same record) and still be bad: a 60-method `User` class touching `user` for authentication, billing, GDPR export and marketing preferences is data-cohesive but has four unrelated *reasons to change* and four different stakeholder groups. That is why the SRP restatement — "gather things that change for the same reason and for the same actor; separate things that change for different reasons" — is the more useful modern criterion. Data cohesion and change cohesion usually agree; when they disagree, follow change. ## How to move up the scale - Coincidental/logical → extract each concern into its own type; replace the type flag with polymorphism (a strategy per variant). - Temporal → keep an `initialize()` orchestrator if you must, but have it *delegate* one line per subsystem, each subsystem owning its own init. - Procedural → push each step's logic into the object that owns the corresponding data (Information Expert), leaving a thin coordinator. - Communicational → split by reason-to-change/actor when the class grows several unrelated method clusters. ## Edge cases - **Temporal cohesion is sometimes correct**: a lifecycle hook, a migration script, an application bootstrap that only delegates. Judged by whether it *contains* logic or merely *sequences* it. - **Logical cohesion is acceptable for stable, closed sets** — a fixed enum of three currencies is not going to grow; the polymorphic refactor may cost more than it saves. - **A genuine stateless utility namespace** (pure math functions) is fine: `MathUtils` full of trigonometry is functionally cohesive around a topic; `Utils` full of string, date, HTTP and file helpers is coincidental. The name tells you which one you have.