System Design LLDDesigning Clean Classes

Designing Clean Classes: The Art of Well-Structured Object-Oriented Code

LevelIntermediate

Duration75 mins

TopicDesigning Clean Classes

4 / 5

Cohesive Members: Creating Unity Within Classes

The Invisible Bond

Imagine a class with five instance variables. Now ask: does every method use most of these variables? Or are there methods that only touch one variable while ignoring the others? Are there variables that only one method ever accesses?

If you can draw a line through the middle of your class, with some methods using some variables on one side and other methods using different variables on the other, you've discovered the hidden seam of low cohesion. Your class is really two classes masquerading as one.

Cohesion is the degree to which the elements of a class belong together. High cohesion means every field and every method works together toward the same purpose. Low cohesion means unrelated functionality has been bundled into a single class by accident of history.

What You Will Master

By the end of this page, you will understand how to measure and evaluate class cohesion, recognize the patterns that indicate low cohesion, and know how to design and refactor classes for maximum cohesion.

Understanding Class Cohesion

Cohesion measures how strongly related and focused the responsibilities of a class are. A highly cohesive class does one thing, and every part of the class contributes to doing that thing well.

Formally, cohesion can be measured by examining how instance variables and methods relate to each other:

Indicators of High Cohesion

•Each method uses most instance variables — Methods operate on the class's shared state rather than isolated pieces.
•Each instance variable is used by most methods — State isn't orphaned; it's central to the class's behavior.
•Methods collaborate through shared state — The result of one method influences another through the instance variables.
•The class cannot be easily split — Attempting to separate the class into two would require duplicating fields or creating tight coupling.
•All methods support the class name — Every method contributes to what the class is named to do.

HighCohesion.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
/**
 * A highly cohesive class: all members work together.
 * 
 * Instance Variables: balance, transactions, accountNumber
 * Every method uses or modifies the shared state.
 */
public class BankAccount {
    private final String accountNumber;  // Used by: getStatement, equals
    private Money balance;               // Used by: deposit, withdraw, getBalance, getStatement
    private List<Transaction> transactions; // Used by: deposit, withdraw, getStatement
    
    public BankAccount(String accountNumber) {
        this.accountNumber = accountNumber;
        this.balance = Money.ZERO;
        this.transactions = new ArrayList<>();
    }
    
    // Uses: balance, transactions
    public void deposit(Money amount) {
        this.balance = this.balance.add(amount);
        this.transactions.add(Transaction.credit(amount));
    }
    
    // Uses: balance, transactions
    public void withdraw(Money amount) {
        if (amount.isGreaterThan(this.balance)) {
            throw new InsufficientFundsException(this.balance, amount);
        }
        this.balance = this.balance.subtract(amount);
        this.transactions.add(Transaction.debit(amount));
    }
    
    // Uses: balance
    public Money getBalance() {
        return this.balance;
    }
    
    // Uses: accountNumber, balance, transactions
    public Statement getStatement(DateRange period) {
        List<Transaction> relevant = this.transactions.stream()
            .filter(t -> period.contains(t.date()))
            .toList();
        return new Statement(this.accountNumber, this.balance, relevant);
    }
}

The Cohesion Visual

Draw a matrix: rows are methods, columns are instance variables. Put a dot where a method uses a variable. High cohesion fills most of the matrix. Low cohesion shows isolated clusters that don't overlap—those clusters should probably be separate classes.

The Cohesion Spectrum

Software engineering literature identifies several levels of cohesion, from weakest to strongest. Understanding this spectrum helps you recognize and improve the cohesion of your classes.

Types of Cohesion (Worst to Best)
Type	Description	Example	Quality
Coincidental	Elements have no meaningful relationship; bundled arbitrarily	Utilities class with random helper methods	❌ Worst
Logical	Elements do similar things but on different data, selected by flag	PrintReport(type) with if/else for each type	❌ Poor
Temporal	Elements execute at the same time but are otherwise unrelated	Startup class that initializes logging, database, and cache	⚠️ Weak
Procedural	Elements are part of the same procedure, executed in sequence	ParseAndValidateAndSave method	⚠️ Weak
Communicational	Elements operate on the same data	CustomerDataProcessor reading/writing customer	✓ Moderate
Sequential	Output of one element feeds into another	Pipeline: Read → Transform → Write	✓ Good
Functional	All elements contribute to a single, well-defined task	Stack class: push, pop, peek, isEmpty	✓ Best

Aim for Functional Cohesion

•Functional cohesion is the gold standard. The entire class exists to perform one well-defined function. A Stack pushes, pops, and reports its state—all aspects of the same abstraction.
•Sequential and communicational cohesion are acceptable when they represent genuine data flow or data-centric operations.
•Temporal and procedural cohesion often indicate that unrelated operations have been grouped by when they happen rather than what they do. Consider separating.
•Logical and coincidental cohesion are red flags. Classes with these types almost always benefit from decomposition.

Detecting Low Cohesion

Low cohesion doesn't announce itself with syntax errors. It lurks in seemingly working code, gradually making the class harder to understand and maintain. Here are the telltale signs:

Signs of Low Cohesion

•Orphan Variables — Instance variables used by only one method. If a variable doesn't participate in the class's core behavior, it doesn't belong.
•Method Cliques — Groups of methods that use each other's variables but ignore variables used by other groups. The class contains hidden sub-classes.
•Flag Parameters — Methods that take boolean or enum parameters to fundamentally change behavior: process(data, isExport). This often indicates merged responsibilities.
•Many Private Methods — Excessive private methods may indicate procedural code hidden inside an object. Each private method cluster might be its own class.
•Change Coupling — Different parts of the class change for different reasons. Marketing changes affect some methods; security changes affect others.
•Testing Difficulty — You frequently test subsets of methods together but can't test all methods as a coherent unit. The class resists unified testing.
•Unrelated Imports — Import statements span multiple domains (database, networking, UI, security). Diverse dependencies suggest diverse responsibilities.

LowCohesion.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// ❌ LOW COHESION: Two distinct responsibilities in one class
 
public class ReportGenerator {
    
    // === CLIQUE 1: Data Retrieval ===
    private final Database database;      // Used ONLY by Clique 1
    private final QueryBuilder queryBuilder;  // Used ONLY by Clique 1
    
    // === CLIQUE 2: PDF Generation ===
    private final PdfLibrary pdfLibrary;  // Used ONLY by Clique 2
    private final FontManager fontManager; // Used ONLY by Clique 2
    private final TemplateEngine templates; // Used ONLY by Clique 2
    
    // === Clique 1 Methods ===
    public ReportData fetchSalesData(DateRange range) {
        // Uses: database, queryBuilder
        // Does NOT use: pdfLibrary, fontManager, templates
    }
    
    public ReportData fetchInventoryData(Warehouse warehouse) {
        // Uses: database, queryBuilder
        // Does NOT use: pdfLibrary, fontManager, templates
    }
    
    // === Clique 2 Methods ===
    public byte[] generatePdf(ReportData data) {
        // Uses: pdfLibrary, fontManager, templates
        // Does NOT use: database, queryBuilder
    }
    
    public byte[] generateInvoicePdf(Invoice invoice) {
        // Uses: pdfLibrary, fontManager, templates
        // Does NOT use: database, queryBuilder
    }
    
    // THE FIX: Split into ReportDataFetcher and PdfGenerator
}

The Partition Test

If you can partition a class's instance variables into groups where each method only uses one group, you've found the natural class boundaries. Each variable group should become its own class.

Measuring Cohesion: LCOM Metrics

While intuition guides much design work, formal metrics can objectively identify cohesion problems. The most common is LCOM (Lack of Cohesion of Methods), which quantifies how methods share instance variables.

Understanding LCOM

•LCOM1 — Counts pairs of methods that share no instance variables. Higher numbers indicate lower cohesion.
•LCOM2 — Refines LCOM1 by subtracting pairs that DO share variables. Negative values (conventionally shown as 0) indicate high cohesion.
•LCOM3 — Counts connected components in the method-variable graph. LCOM3 > 1 suggests the class should be split into that many classes.
•LCOM4 — Like LCOM3 but also considers method-to-method calls. More accurate for classes with helper methods.

LCOMExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
/**
 * LCOM Analysis Example
 * 
 * Class with 3 methods (m1, m2, m3) and 4 variables (a, b, c, d)
 * 
 * Method-Variable Matrix:
 *           a    b    c    d
 *    m1     ✓    ✓    
 *    m2     ✓    ✓    
 *    m3               ✓    ✓
 * 
 * Graph visualization:
 *    [m1]---a---[m2]      [m3]---c---[d]
 *      \     /              \     /
 *        -b-                    (isolated!)
 * 
 * LCOM3 = 2 (two connected components)
 * This class should be split into TWO classes!
 */
 
// Original: Low cohesion
class Original {
    int a, b, c, d;
    
    void m1() { /* uses a, b */ }
    void m2() { /* uses a, b */ }
    void m3() { /* uses c, d */ }  // Disconnected!
}
 
// After split: Two highly cohesive classes
class ComponentOne {
    int a, b;
    void m1() { /* uses a, b */ }
    void m2() { /* uses a, b */ }
    // LCOM3 = 1 ✓
}
 
class ComponentTwo {
    int c, d;
    void m3() { /* uses c, d */ }
    // LCOM3 = 1 ✓
}

Tools for LCOM Analysis

Most static analysis tools (SonarQube, CodeClimate, IntelliJ's built-in analysis) can compute LCOM metrics. Use them as early warning systems: when LCOM scores spike, investigate the class's cohesion.

Designing for High Cohesion

Rather than detecting and fixing low cohesion after the fact, design classes with cohesion in mind from the start. These strategies help you create cohesive classes naturally:

Cohesion-First Design Strategies

•Start with State — Before writing methods, define the minimal state the class needs. List the instance variables that must live together. Methods will operate on this shared state.
•Name the Responsibility — Write a one-sentence description of the class's purpose. If every method doesn't serve that sentence, the method doesn't belong.
•Maximize Field Usage — As you add methods, ask: 'Does this method use the class's core state?' If not, the method may belong elsewhere.
•Minimize Parameters — Methods that receive most of their data as parameters rather than from instance variables are candidates for extraction. They're not truly 'of' this class.
•Watch for Accessor Chains — If methods primarily call getters on collaborators, consider moving the method to the collaborator. This is 'Feature Envy.'
•Reject Convenience — Resist adding methods 'because they're related.' A Customer class shouldn't have sendEmail()—that's EmailService's job, even if customers receive emails.

The 'Use All Fields' Heuristic

A useful heuristic: every method should use at least half of the instance variables. If a method only touches one field, question why it's a method of this class rather than a free function or a method of another class.

Refactoring for Better Cohesion

When you've identified low cohesion in existing code, specific refactoring techniques can improve it. Each technique addresses a particular cohesion problem:

Cohesion Refactoring Techniques

•Extract Class — When you find method cliques, extract each clique into its own class. The original class becomes a coordinator or is eliminated.
•Move Method — When a method primarily uses another object's data (Feature Envy), move the method to that object. The method should live with the data it operates on.
•Replace Parameter with Method — When a method takes parameters it could compute from instance state, eliminate the parameters. This strengthens the method's connection to the class.
•Remove Middleman — When a class mostly delegates to another, consider eliminating the middleman. Unnecessary indirection creates artificial 'classes' that aren't really doing anything.
•Inline Class — When a class has very little behavior, inline it into its primary client. Over-decomposition creates false classes that dilute cohesion system-wide.

ExtractClassRefactoring.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// BEFORE: Low cohesion - Employee with embedded phone handling
 
class Employee {
    private String name;
    private String department;
    private double salary;
    
    // Phone fields - separate concern!
    private String areaCode;
    private String number;
    private String extension;
    
    public String getPhoneNumber() {
        return "(" + areaCode + ") " + number + " ext " + extension;
    }
    
    public void updatePhone(String area, String num, String ext) {
        this.areaCode = area;
        this.number = num;
        this.extension = ext;
    }
    
    public boolean isSameAreaCode(String area) {
        return this.areaCode.equals(area);
    }
    
    // Employee methods that don't touch phone...
}
 
 
// AFTER: Extracted TelephoneNumber class
 
class TelephoneNumber {
    private final String areaCode;
    private final String number;
    private final String extension;
    
    public TelephoneNumber(String areaCode, String number, String extension) {
        this.areaCode = areaCode;
        this.number = number;
        this.extension = extension;
    }
    
    public String formatted() {
        return "(" + areaCode + ") " + number + " ext " + extension;
    }
    
    public boolean isInArea(String area) {
        return this.areaCode.equals(area);
    }
}
 
class Employee {
    private String name;
    private String department;
    private double salary;
    private TelephoneNumber phone;  // Cohesive composition
    
    // Employee now focused on employee concerns
}

Cohesion and Coupling: The Dual Forces

Cohesion and coupling are two sides of the same design coin. They work together to determine how maintainable a system is:

Cohesion is internal: how strongly elements within a class belong together.
Coupling is external: how closely classes depend on each other.

The goal is high cohesion, low coupling. Classes should be internally unified but externally independent.

Maximize Cohesion

•Every member serves the same purpose
•Methods share instance variables
•Hard to split without duplication
•Changes are localized
•Easy to understand in isolation

Minimize Coupling

•Classes depend on abstractions
•Changes don't cascade
•Classes are independently deployable
•Testing requires minimal mocking
•Classes can be reused elsewhere

The Tradeoff

Increasing cohesion sometimes increases coupling (moving methods requires new dependencies). Decreasing coupling sometimes decreases cohesion (introducing intermediaries). The art is finding the balance where both are acceptable. Usually, prioritize cohesion within classes and manage coupling through well-designed interfaces.

Summary: The Cohesive Class

Cohesion is the invisible force that makes classes understandable and maintainable. When every member of a class contributes to the same purpose, the class becomes a coherent unit—easy to understand, easy to test, and easy to change.

Key Takeaways

•Cohesion measures unity — High cohesion means every element works together toward a single purpose.
•Functional cohesion is the goal — All elements contribute to one well-defined task.
•Detection is visual — Method-variable matrices reveal hidden cliques and orphan variables.
•LCOM metrics quantify cohesion — LCOM3 > 1 suggests the class should be split.
•Design for cohesion from the start — Define state first, then add methods that operate on that state.
•Extract Class fixes low cohesion — When cliques emerge, extract them into focused classes.
•High cohesion, low coupling — These twin goals create maintainable systems.

What's next:

With single purpose, meaningful names, appropriate size, and cohesive members established, we conclude with a class design checklist—a practical summary of all principles that you can apply to every class you design or review.

Page Complete

You now understand class cohesion—what it means, how to measure it, how to design for it, and how to refactor toward it. Next, we'll consolidate everything into an actionable class design checklist.

4 / 5

Loading learning content...

System Design LLDDesigning Clean Classes

Designing Clean Classes: The Art of Well-Structured Object-Oriented Code

LevelIntermediate

Duration75 mins

TopicDesigning Clean Classes

4 / 5

Cohesive Members: Creating Unity Within Classes

The Invisible Bond

What You Will Master

Understanding Class Cohesion

Cohesion measures how strongly related and focused the responsibilities of a class are. A highly cohesive class does one thing, and every part of the class contributes to doing that thing well.

Formally, cohesion can be measured by examining how instance variables and methods relate to each other:

Indicators of High Cohesion

•Each method uses most instance variables — Methods operate on the class's shared state rather than isolated pieces.
•Each instance variable is used by most methods — State isn't orphaned; it's central to the class's behavior.
•Methods collaborate through shared state — The result of one method influences another through the instance variables.
•The class cannot be easily split — Attempting to separate the class into two would require duplicating fields or creating tight coupling.
•All methods support the class name — Every method contributes to what the class is named to do.

HighCohesion.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
/**
 * A highly cohesive class: all members work together.
 * 
 * Instance Variables: balance, transactions, accountNumber
 * Every method uses or modifies the shared state.
 */
public class BankAccount {
    private final String accountNumber;  // Used by: getStatement, equals
    private Money balance;               // Used by: deposit, withdraw, getBalance, getStatement
    private List<Transaction> transactions; // Used by: deposit, withdraw, getStatement
    
    public BankAccount(String accountNumber) {
        this.accountNumber = accountNumber;
        this.balance = Money.ZERO;
        this.transactions = new ArrayList<>();
    }
    
    // Uses: balance, transactions
    public void deposit(Money amount) {
        this.balance = this.balance.add(amount);
        this.transactions.add(Transaction.credit(amount));
    }
    
    // Uses: balance, transactions
    public void withdraw(Money amount) {
        if (amount.isGreaterThan(this.balance)) {
            throw new InsufficientFundsException(this.balance, amount);
        }
        this.balance = this.balance.subtract(amount);
        this.transactions.add(Transaction.debit(amount));
    }
    
    // Uses: balance
    public Money getBalance() {
        return this.balance;
    }
    
    // Uses: accountNumber, balance, transactions
    public Statement getStatement(DateRange period) {
        List<Transaction> relevant = this.transactions.stream()
            .filter(t -> period.contains(t.date()))
            .toList();
        return new Statement(this.accountNumber, this.balance, relevant);
    }
}

The Cohesion Visual

The Cohesion Spectrum

Software engineering literature identifies several levels of cohesion, from weakest to strongest. Understanding this spectrum helps you recognize and improve the cohesion of your classes.

Types of Cohesion (Worst to Best)
Type	Description	Example	Quality
Coincidental	Elements have no meaningful relationship; bundled arbitrarily	Utilities class with random helper methods	❌ Worst
Logical	Elements do similar things but on different data, selected by flag	PrintReport(type) with if/else for each type	❌ Poor
Temporal	Elements execute at the same time but are otherwise unrelated	Startup class that initializes logging, database, and cache	⚠️ Weak
Procedural	Elements are part of the same procedure, executed in sequence	ParseAndValidateAndSave method	⚠️ Weak
Communicational	Elements operate on the same data	CustomerDataProcessor reading/writing customer	✓ Moderate
Sequential	Output of one element feeds into another	Pipeline: Read → Transform → Write	✓ Good
Functional	All elements contribute to a single, well-defined task	Stack class: push, pop, peek, isEmpty	✓ Best

Aim for Functional Cohesion

•Functional cohesion is the gold standard. The entire class exists to perform one well-defined function. A Stack pushes, pops, and reports its state—all aspects of the same abstraction.
•Sequential and communicational cohesion are acceptable when they represent genuine data flow or data-centric operations.
•Temporal and procedural cohesion often indicate that unrelated operations have been grouped by when they happen rather than what they do. Consider separating.
•Logical and coincidental cohesion are red flags. Classes with these types almost always benefit from decomposition.

Detecting Low Cohesion

Low cohesion doesn't announce itself with syntax errors. It lurks in seemingly working code, gradually making the class harder to understand and maintain. Here are the telltale signs:

Signs of Low Cohesion

•Orphan Variables — Instance variables used by only one method. If a variable doesn't participate in the class's core behavior, it doesn't belong.
•Method Cliques — Groups of methods that use each other's variables but ignore variables used by other groups. The class contains hidden sub-classes.
•Flag Parameters — Methods that take boolean or enum parameters to fundamentally change behavior: process(data, isExport). This often indicates merged responsibilities.
•Many Private Methods — Excessive private methods may indicate procedural code hidden inside an object. Each private method cluster might be its own class.
•Change Coupling — Different parts of the class change for different reasons. Marketing changes affect some methods; security changes affect others.
•Testing Difficulty — You frequently test subsets of methods together but can't test all methods as a coherent unit. The class resists unified testing.
•Unrelated Imports — Import statements span multiple domains (database, networking, UI, security). Diverse dependencies suggest diverse responsibilities.

LowCohesion.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// ❌ LOW COHESION: Two distinct responsibilities in one class
 
public class ReportGenerator {
    
    // === CLIQUE 1: Data Retrieval ===
    private final Database database;      // Used ONLY by Clique 1
    private final QueryBuilder queryBuilder;  // Used ONLY by Clique 1
    
    // === CLIQUE 2: PDF Generation ===
    private final PdfLibrary pdfLibrary;  // Used ONLY by Clique 2
    private final FontManager fontManager; // Used ONLY by Clique 2
    private final TemplateEngine templates; // Used ONLY by Clique 2
    
    // === Clique 1 Methods ===
    public ReportData fetchSalesData(DateRange range) {
        // Uses: database, queryBuilder
        // Does NOT use: pdfLibrary, fontManager, templates
    }
    
    public ReportData fetchInventoryData(Warehouse warehouse) {
        // Uses: database, queryBuilder
        // Does NOT use: pdfLibrary, fontManager, templates
    }
    
    // === Clique 2 Methods ===
    public byte[] generatePdf(ReportData data) {
        // Uses: pdfLibrary, fontManager, templates
        // Does NOT use: database, queryBuilder
    }
    
    public byte[] generateInvoicePdf(Invoice invoice) {
        // Uses: pdfLibrary, fontManager, templates
        // Does NOT use: database, queryBuilder
    }
    
    // THE FIX: Split into ReportDataFetcher and PdfGenerator
}

The Partition Test

If you can partition a class's instance variables into groups where each method only uses one group, you've found the natural class boundaries. Each variable group should become its own class.

Measuring Cohesion: LCOM Metrics

Understanding LCOM

•LCOM1 — Counts pairs of methods that share no instance variables. Higher numbers indicate lower cohesion.
•LCOM2 — Refines LCOM1 by subtracting pairs that DO share variables. Negative values (conventionally shown as 0) indicate high cohesion.
•LCOM3 — Counts connected components in the method-variable graph. LCOM3 > 1 suggests the class should be split into that many classes.
•LCOM4 — Like LCOM3 but also considers method-to-method calls. More accurate for classes with helper methods.

LCOMExample.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
/**
 * LCOM Analysis Example
 * 
 * Class with 3 methods (m1, m2, m3) and 4 variables (a, b, c, d)
 * 
 * Method-Variable Matrix:
 *           a    b    c    d
 *    m1     ✓    ✓    
 *    m2     ✓    ✓    
 *    m3               ✓    ✓
 * 
 * Graph visualization:
 *    [m1]---a---[m2]      [m3]---c---[d]
 *      \     /              \     /
 *        -b-                    (isolated!)
 * 
 * LCOM3 = 2 (two connected components)
 * This class should be split into TWO classes!
 */
 
// Original: Low cohesion
class Original {
    int a, b, c, d;
    
    void m1() { /* uses a, b */ }
    void m2() { /* uses a, b */ }
    void m3() { /* uses c, d */ }  // Disconnected!
}
 
// After split: Two highly cohesive classes
class ComponentOne {
    int a, b;
    void m1() { /* uses a, b */ }
    void m2() { /* uses a, b */ }
    // LCOM3 = 1 ✓
}
 
class ComponentTwo {
    int c, d;
    void m3() { /* uses c, d */ }
    // LCOM3 = 1 ✓
}

Tools for LCOM Analysis

Designing for High Cohesion

Rather than detecting and fixing low cohesion after the fact, design classes with cohesion in mind from the start. These strategies help you create cohesive classes naturally:

Cohesion-First Design Strategies

•Start with State — Before writing methods, define the minimal state the class needs. List the instance variables that must live together. Methods will operate on this shared state.
•Name the Responsibility — Write a one-sentence description of the class's purpose. If every method doesn't serve that sentence, the method doesn't belong.
•Maximize Field Usage — As you add methods, ask: 'Does this method use the class's core state?' If not, the method may belong elsewhere.
•Minimize Parameters — Methods that receive most of their data as parameters rather than from instance variables are candidates for extraction. They're not truly 'of' this class.
•Watch for Accessor Chains — If methods primarily call getters on collaborators, consider moving the method to the collaborator. This is 'Feature Envy.'
•Reject Convenience — Resist adding methods 'because they're related.' A Customer class shouldn't have sendEmail()—that's EmailService's job, even if customers receive emails.

The 'Use All Fields' Heuristic

Refactoring for Better Cohesion

When you've identified low cohesion in existing code, specific refactoring techniques can improve it. Each technique addresses a particular cohesion problem:

Cohesion Refactoring Techniques

•Extract Class — When you find method cliques, extract each clique into its own class. The original class becomes a coordinator or is eliminated.
•Move Method — When a method primarily uses another object's data (Feature Envy), move the method to that object. The method should live with the data it operates on.
•Replace Parameter with Method — When a method takes parameters it could compute from instance state, eliminate the parameters. This strengthens the method's connection to the class.
•Remove Middleman — When a class mostly delegates to another, consider eliminating the middleman. Unnecessary indirection creates artificial 'classes' that aren't really doing anything.
•Inline Class — When a class has very little behavior, inline it into its primary client. Over-decomposition creates false classes that dilute cohesion system-wide.

ExtractClassRefactoring.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
// BEFORE: Low cohesion - Employee with embedded phone handling
 
class Employee {
    private String name;
    private String department;
    private double salary;
    
    // Phone fields - separate concern!
    private String areaCode;
    private String number;
    private String extension;
    
    public String getPhoneNumber() {
        return "(" + areaCode + ") " + number + " ext " + extension;
    }
    
    public void updatePhone(String area, String num, String ext) {
        this.areaCode = area;
        this.number = num;
        this.extension = ext;
    }
    
    public boolean isSameAreaCode(String area) {
        return this.areaCode.equals(area);
    }
    
    // Employee methods that don't touch phone...
}
 
 
// AFTER: Extracted TelephoneNumber class
 
class TelephoneNumber {
    private final String areaCode;
    private final String number;
    private final String extension;
    
    public TelephoneNumber(String areaCode, String number, String extension) {
        this.areaCode = areaCode;
        this.number = number;
        this.extension = extension;
    }
    
    public String formatted() {
        return "(" + areaCode + ") " + number + " ext " + extension;
    }
    
    public boolean isInArea(String area) {
        return this.areaCode.equals(area);
    }
}
 
class Employee {
    private String name;
    private String department;
    private double salary;
    private TelephoneNumber phone;  // Cohesive composition
    
    // Employee now focused on employee concerns
}

Cohesion and Coupling: The Dual Forces

Cohesion and coupling are two sides of the same design coin. They work together to determine how maintainable a system is:

Cohesion is internal: how strongly elements within a class belong together.
Coupling is external: how closely classes depend on each other.

The goal is high cohesion, low coupling. Classes should be internally unified but externally independent.

Maximize Cohesion

•Every member serves the same purpose
•Methods share instance variables
•Hard to split without duplication
•Changes are localized
•Easy to understand in isolation

Minimize Coupling

•Classes depend on abstractions
•Changes don't cascade
•Classes are independently deployable
•Testing requires minimal mocking
•Classes can be reused elsewhere

The Tradeoff

Summary: The Cohesive Class

Key Takeaways

•Cohesion measures unity — High cohesion means every element works together toward a single purpose.
•Functional cohesion is the goal — All elements contribute to one well-defined task.
•Detection is visual — Method-variable matrices reveal hidden cliques and orphan variables.
•LCOM metrics quantify cohesion — LCOM3 > 1 suggests the class should be split.
•Design for cohesion from the start — Define state first, then add methods that operate on that state.
•Extract Class fixes low cohesion — When cliques emerge, extract them into focused classes.
•High cohesion, low coupling — These twin goals create maintainable systems.

What's next:

Page Complete

4 / 5