apply-high-cohesion

name	apply-high-cohesion
description	Use when assigning responsibilities to classes — especially when a class is hard to name, does work unrelated to its core concept, or a single change requires understanding an entire class to avoid breaking something.
source	Craig Larman, "Applying UML and Patterns", 3rd ed., Prentice Hall, 2004
tags	["grasp","high-cohesion","design-principles","oop","responsibility-assignment","developer","readability","maintainability"]
related	["apply-low-coupling","apply-information-expert","apply-solid-principles","apply-unix-philosophy"]

Apply High Cohesion

Assign responsibilities so that each class remains focused on one strongly related set of concerns that can be understood and explained as a unit.

Why This Is Best Practice

Adopted by: GRASP (Larman, 2004); SOLID SRP (Martin, 2003); Unix philosophy; Go standard library design (small, focused interfaces). High cohesion is a foundational metric in software quality measurement — Chidamber & Kemerer (1994, IEEE TSE) established the Lack of Cohesion of Methods (LCOM) metric, now a standard quality gate in SonarQube, CodeClimate, and NDepend. Impact: Chidamber & Kemerer (1994) showed that LCOM is inversely correlated with fault-proneness — low-cohesion classes have statistically higher defect density. Palomba et al. (2018, IEEE TSE) confirmed that God Classes (the archetypal low-cohesion pattern) have 3–4x higher change frequency than average classes. High-cohesion classes are self-documenting: the class name describes everything inside it. Why best: Low cohesion grows through feature accretion — each new feature lands in the nearest existing class rather than the right class. The result is a God Class that knows everything and changes for every reason. High cohesion is not achieved by refusing to add features; it is achieved by asking "does this feature belong here, or in a focused class I haven't created yet?" The distinction between High Cohesion (GRASP) and SRP (SOLID) is axis: SRP asks "how many actors would cause this to change?"; High Cohesion asks "how related are the operations this class performs?"

Sources: Larman, "Applying UML and Patterns" (Prentice Hall, 2004); Chidamber & Kemerer, "A Metrics Suite for Object-Oriented Design" (IEEE TSE, 1994); Palomba et al., "Revisiting the Impact of Code Smells" (IEEE TSE, 2018)

Steps

1. Apply the name test

A highly cohesive class can be named with one noun and a short description. If the name requires "And" or a vague term like "Manager", "Handler", or "Util", it is likely doing too much.

Name	Signal
OrderCalculator	Cohesive — one focused operation
UserManager	Suspicious — "manage" hides multiple concerns
OrderAndPaymentService	Low cohesion — explicitly two concerns
Utils	No cohesion — a wastebasket class

---

2. Measure LCOM: count unrelated method groups

List all instance methods. Draw a line between two methods if they share an instance variable. Disconnected groups signal low cohesion — the class contains multiple independent clusters that belong in separate classes.

# Low cohesion — two disconnected groups: reporting and user management
class UserService:
    def find_user(self, id): return self.user_db.find(id)       # group A: uses user_db
    def update_email(self, id, email): ...                      # group A: uses user_db
    def generate_monthly_report(self): ...                      # group B: uses report_db
    def export_report_csv(self): ...                            # group B: uses report_db
    # A and B never share an instance variable — this is two classes

# High cohesion — split into two focused classes
class UserRepository:
    def find(self, id): ...
    def update_email(self, id, email): ...

class UserReportGenerator:
    def generate_monthly(self): ...
    def export_csv(self): ...

---

3. Assign new responsibilities to the most cohesion-preserving class

When adding a feature, evaluate each candidate class by asking: "does this responsibility relate to the existing operations in that class?"

• If yes and LCOM would not increase: assign it there
• If no or LCOM would increase: create a new focused class
• If yes but the class is already large: extract the related group first, then assign

---

4. Split God Classes by responsibility cluster

A God Class is a class that has grown to encompass unrelated responsibilities. Split it by identifying distinct clusters of methods and data, each of which belongs together.

# God Class — OrderSystem does everything
class OrderSystem:
    def place_order(self): ...        # ordering
    def cancel_order(self): ...       # ordering
    def charge_payment(self): ...     # payment
    def refund_payment(self): ...     # payment
    def send_confirmation(self): ...  # notification
    def send_cancellation(self): ...  # notification
    def generate_invoice(self): ...   # invoicing

# Split into 4 cohesive classes
class OrderManager:     # ordering
class PaymentProcessor: # payment
class Notifier:         # notification
class InvoiceGenerator: # invoicing

---

5. Balance against low coupling

Splitting a class too aggressively raises coupling — each new class needs to know about others. Find the natural split: separate what has different rates of change or different collaborators, not what merely appears in different lines.

A class with 8 cohesive methods serving one concept is better than 4 classes of 2 methods each that all call each other.

Common Mistakes

Splitting by operation type instead of concept. Moving all "create" methods to one class and all "update" methods to another produces structural cohesion but not conceptual cohesion. Group by domain concept, not by CRUD verb.

Equating cohesion with size. A small class can be incoherent (two unrelated methods). A large class can be highly cohesive (50 methods all serving one complex domain concept, like a geometry engine). Measure by relatedness, not line count.

Confusing High Cohesion with SRP. SRP asks: how many actors need this to change? High Cohesion asks: how related are the responsibilities? Both point at the same smell (bloated classes) but from different angles. Applying both gives the clearest guidance.

When NOT to Use

• Facade classes — deliberately aggregate multiple subsystems behind a simplified interface; their broad responsibility is intentional
• Entry-point / bootstrap classes — application startup code necessarily wires many components together; this is coordination, not low cohesion
• Value objects and data classes — pure data structures with no behavior have no cohesion to measure