Book 09 · Software ArchitecturePage 7 of 48

Cohesion

In Turkish: Uyum
Pronunciation: koh-HEE-zhun

Updated September 30, 20262 min read

In short

Cohesion is a measure of how closely the responsibilities inside a module, class, or service belong together, and high cohesion is a sign of good design.

What is cohesion in software design?

Cohesion describes how strongly the parts of a single module relate to each other. A class with high cohesion does one well-defined job, and all its methods and data serve that job, like an InvoiceCalculator that only computes totals, taxes, and discounts. A class with low cohesion is a grab bag of unrelated tasks, like a Utils class that formats dates, sends emails, and resizes images.

The idea comes from structured design in the 1970s, which ranked kinds of cohesion from weakest to strongest. Coincidental cohesion, where things are grouped for no real reason, is the worst, and functional cohesion, where everything contributes to a single task, is the best. Warning signs of low cohesion include vague names like Manager or Helper, methods that use completely different fields, and a class that has to change for many unrelated reasons; the single responsibility principle in SOLID is essentially a rule for high cohesion.

A well-organized kitchen is a good analogy: one drawer holds only cutlery and another only baking tools, so you know exactly where to look. The junk drawer, full of batteries, rubber bands, and old keys, is low cohesion. The same idea applies to services, where grouping code by business capability, such as billing or shipping, gives each service a clear purpose.

Cohesion is often confused with coupling, and the two are usually discussed together. Cohesion is about how well the things inside one module belong together, while coupling is about how much separate modules depend on each other, and the goal is high cohesion combined with loose coupling. High cohesion also doesn't simply mean small: splitting a cohesive class into many tiny ones can scatter a single responsibility across files and increase coupling.

Key takeaways

Cohesion measures how well a module's contents belong together.
High cohesion means one clear responsibility; low cohesion means a grab bag.
The single responsibility principle is a rule for achieving high cohesion.
Aim for high cohesion inside modules and loose coupling between them.
Cohesive doesn't mean tiny; split by responsibility, not by size.

Example

Low cohesion versus high cohesiontypescript

// Low cohesion: unrelated jobs living in one class
class AppHelper {
  formatDate(d: Date) { /* ... */ }
  sendWelcomeEmail(to: string) { /* ... */ }
  resizeImage(file: Blob) { /* ... */ }
}

// High cohesion: each class has one clear purpose
class DateFormatter { format(d: Date) { /* ... */ } }
class WelcomeMailer { send(to: string) { /* ... */ } }
class ImageResizer { resize(file: Blob) { /* ... */ } }

Readers ask

What is the difference between coupling and cohesion?

Cohesion describes how closely related the responsibilities inside one module are, while coupling describes how much different modules depend on each other. Good designs combine high cohesion within modules with loose coupling between them.

How do you measure cohesion?

Informally, check whether a module has one clear purpose you can describe in a sentence and whether its methods work with the same data. Static analysis tools can also compute metrics such as LCOM (lack of cohesion of methods), which flags classes whose methods share few fields.

How is cohesion related to the single responsibility principle?

The single responsibility principle says a class should have only one reason to change. Following it naturally produces high cohesion, because everything in the class serves the same responsibility.