System DesignClasses & Objects

Attributes and Methods

LevelBeginner

Duration60 mins

TopicClasses & Objects

4 / 4

Designing Cohesive Methods

The Harmony of Well-Designed Methods

A class is more than a bag of loosely related methods. In well-designed systems, methods work together harmoniously—each method has a clear purpose, methods support each other, and together they fully express what the class can do. This quality is called cohesion.

Cohesive methods are like musicians in an orchestra: each plays their part, and together they create something greater than the sum of individual contributions. Incohesive methods are like a random group playing different songs—technically functional but chaotic and hard to follow.

What You Will Learn

By the end of this page, you will understand the principles of method cohesion, know how to design methods that are focused and purposeful, recognize the signs of poorly designed methods, and create classes whose methods work together as a unified whole.

What Is Cohesion?

Cohesion measures how strongly related the elements within a module (class, method, or function) are to each other. High cohesion means elements belong together—they work toward a common purpose. Low cohesion means elements are loosely related or unrelated—they happen to be in the same container but don't form a coherent unit.

At the method level, cohesion asks:

Does this method do one thing well?
Is everything in this method related to that one thing?
Does removing any line break the method's purpose?

At the class level, cohesion asks:

Do all methods operate on the same data?
Do methods support a single, focused responsibility?
Would any method make more sense in a different class?

Levels of Cohesion (from best to worst)
Cohesion Type	Description	Quality
Functional	All elements contribute to a single, well-defined task	Best ✓
Sequential	Output of one element feeds into the next	Good
Communicational	Elements operate on the same data	Acceptable
Procedural	Elements are grouped because they happen in sequence	Weak
Temporal	Elements are grouped because they execute at the same time	Weak
Logical	Elements are grouped by category but do different things	Poor
Coincidental	Elements have no meaningful relationship	Worst ✗

The Cohesion Test

Can you describe what a method does in a single sentence without using 'and' or 'or'? If not, the method may be doing too many things. 'This method validates the order AND sends a confirmation email' suggests two responsibilities.

Single Responsibility for Methods

The Single Responsibility Principle (SRP) applies not just to classes but to methods. Each method should have one reason to change—one focused purpose.

Signs a Method Has Multiple Responsibilities:

Long methods: More than 20-30 lines often indicates multiple tasks
Many parameters: Different parts of the method use different parameters
Multiple levels of abstraction: Mixing high-level logic with low-level details
Comment markers: // Step 1: Validate, // Step 2: Process, // Step 3: Save
Disconnected sections: Blank lines separating unrelated code blocks
Hard to name: The only accurate name includes 'and' or is vague like 'processData'

BeforeRefactoring.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
// BEFORE: Low cohesion - multiple responsibilities in one method
public void processOrder(Order order) {
    // Responsibility 1: Validation
    if (order.getItems().isEmpty()) {
        throw new ValidationException("Order must have items");
    }
    if (order.getCustomer() == null) {
        throw new ValidationException("Order must have a customer");
    }
    for (Item item : order.getItems()) {
        if (item.getQuantity() <= 0) {
            throw new ValidationException("Invalid quantity");
        }
    }
    
    // Responsibility 2: Pricing calculations
    double subtotal = 0;
    for (Item item : order.getItems()) {
        subtotal += item.getPrice() * item.getQuantity();
    }
    double tax = subtotal * 0.08;
    double shipping = calculateShipping(order);
    double total = subtotal + tax + shipping;
    order.setTotal(total);
    
    // Responsibility 3: Inventory update
    for (Item item : order.getItems()) {
        inventoryService.decrementStock(item.getProductId(), item.getQuantity());
    }
    
    // Responsibility 4: Persistence
    orderRepository.save(order);
    
    // Responsibility 5: Notification
    emailService.sendOrderConfirmation(order);
    
    // Responsibility 6: Analytics
    analyticsService.trackOrderPlaced(order);
}

AfterRefactoring.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
// AFTER: High cohesion - each method has one purpose
public void processOrder(Order order) {
    validate(order);
    calculatePricing(order);
    reserveInventory(order);
    save(order);
    notifyAndTrack(order);
}
 
private void validate(Order order) {
    orderValidator.validate(order);  // Dedicated validator
}
 
private void calculatePricing(Order order) {
    PricingResult pricing = pricingService.calculate(order);
    order.applyPricing(pricing);
}
 
private void reserveInventory(Order order) {
    inventoryService.reserve(order.getItems());
}
 
private void save(Order order) {
    orderRepository.save(order);
}
 
private void notifyAndTrack(Order order) {
    eventPublisher.publish(new OrderPlacedEvent(order));
    // Listeners handle email, analytics, etc.
}

Abstraction Levels

Notice how the refactored code reads like prose: validate, calculate, reserve, save, notify. Each line is at the same level of abstraction. The details are pushed into helper methods or dedicated services. This is the 'Newspaper' metaphor: headlines at the top, details below.

Method Length and Complexity

While there's no magic number, method length and complexity are strong signals of cohesion.

Guidelines for Method Length:

Ideal: 5-15 lines that fit on one screen
Acceptable: Up to 30 lines for complex algorithms
Concerning: 50+ lines (almost always needs refactoring)
Critical: 100+ lines (definitely needs refactoring)

Cyclomatic Complexity:

Cyclomatic complexity counts the number of independent paths through a method. Each if, else, for, while, case, catch, and &&/|| adds a path.

1-4: Simple, easy to test
5-7: Moderate complexity
8-10: High complexity, consider refactoring
11+: Very complex, hard to test and maintain

Signs of Excessive Complexity

•Deeply nested if/else blocks
•Multiple return statements scattered throughout
•Loops with complex exit conditions
•Many variables with overlapping scopes
•Hard to trace which path executes

Techniques to Reduce Complexity

•Extract conditional logic to methods
•Use guard clauses for early returns
•Replace conditionals with polymorphism
•Extract loops into well-named methods
•Use the Strategy pattern for variants

ReducingComplexity.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
// BEFORE: High complexity - many nesting levels
public double calculateDiscount(Customer customer, Order order) {
    double discount = 0;
    if (customer != null) {
        if (customer.getMembershipLevel() != null) {
            if (customer.getMembershipLevel() == MembershipLevel.GOLD) {
                discount = 0.15;
            } else if (customer.getMembershipLevel() == MembershipLevel.SILVER) {
                discount = 0.10;
            } else if (customer.getMembershipLevel() == MembershipLevel.BRONZE) {
                discount = 0.05;
            }
        }
        if (order.getTotal() > 100) {
            discount += 0.02;
        }
        if (isHolidaySeason()) {
            discount += 0.05;
        }
    }
    return discount;
}
 
// AFTER: Reduced complexity - guard clauses, extracted methods
public double calculateDiscount(Customer customer, Order order) {
    if (customer == null) return 0;  // Guard clause
    
    double discount = getMembershipDiscount(customer);
    discount += getLargeOrderDiscount(order);
    discount += getSeasonalDiscount();
    
    return discount;
}
 
private double getMembershipDiscount(Customer customer) {
    MembershipLevel level = customer.getMembershipLevel();
    if (level == null) return 0;
    
    return switch (level) {
        case GOLD -> 0.15;
        case SILVER -> 0.10;
        case BRONZE -> 0.05;
    };
}
 
private double getLargeOrderDiscount(Order order) {
    return order.getTotal() > 100 ? 0.02 : 0;
}
 
private double getSeasonalDiscount() {
    return isHolidaySeason() ? 0.05 : 0;
}

Method Naming

Method names are the primary documentation for what a method does. A well-named method doesn't need comments—its name explains its purpose.

Naming Principles:

Use verbs or verb phrases: Methods are actions (calculateTotal, sendEmail)
Be specific: sendOrderConfirmationEmail over send
Indicate what, not how: sortByDate over quickSortByDateField
Boolean methods read as questions: isValid, hasItems, canProceed
Use consistent vocabulary: If you use fetch for one retrieval, use it everywhere
Match method behavior to name: Don't name something getX if it modifies state

Method Naming Patterns
Pattern	Convention	Examples
Getters	getPropertyName()	getBalance(), getName(), getItems()
Setters	setPropertyName(value)	setBalance(amount), setStatus(status)
Boolean queries	isCondition(), hasProperty()	isActive(), isEmpty(), hasPermission()
Actions	verbNoun()	sendEmail(), createOrder(), deleteUser()
Conversions	toFormat(), asType()	toString(), toJson(), asList()
Computations	calculateX(), computeX()	calculateTotal(), computeHash()
Factory methods	createX(), of(), from()	createDefault(), of(value), fromString()
Finders	findByX(), getByX()	findByEmail(), getById()

Name Lies

The worst methods are those with misleading names. A 'getUser' that creates users on cache miss. A 'validate' that also saves. A 'toString' that has side effects. If the name doesn't match the behavior, either rename the method or fix the behavior.

The Intention-Revealing Name:

A method's name should reveal its intention—why you would call it, not just what it does.

Compare:

process(data) — Process how? Why would I call this?
calculateMonthlyPayment(loan) — Clear purpose, clear input

Compare:

handleEvent(event) — What does 'handle' mean?
updateInventoryOnPurchase(event) — Exactly what happens and when

Parameter Design for Cohesion

Method parameters significantly impact cohesion. Too many parameters often indicate a method doing too much.

Parameter Count Guidelines:

0 parameters: Ideal for getters and methods using only instance state
1-2 parameters: Comfortable, easy to use
3 parameters: Acceptable but consider alternatives
4+ parameters: Code smell; consider a parameter object

Why Many Parameters Hurt Cohesion:

Hard to remember parameter order
Easy to mix up similar-typed parameters
Suggests method does multiple things (different params for different parts)
Makes testing combinatorially complex

ParameterObjectPattern.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
// BEFORE: Too many parameters
public void scheduleDelivery(
    String customerId,
    String address,
    String city,
    String zipCode,
    LocalDate preferredDate,
    TimeSlot preferredTime,
    boolean requiresSignature,
    boolean isFragile,
    String specialInstructions
) {
    // Implementation
}
 
// AFTER: Parameter object encapsulates related data
public void scheduleDelivery(DeliveryRequest request) {
    // Implementation
}
 
public class DeliveryRequest {
    private final String customerId;
    private final Address address;  // Groups address components
    private final DeliveryWindow window;  // Groups date/time
    private final DeliveryOptions options;  // Groups flags
    
    // Builder pattern for flexible construction
    public static Builder builder(String customerId) {
        return new Builder(customerId);
    }
    
    public static class Builder {
        private String customerId;
        private Address address;
        private DeliveryWindow window;
        private DeliveryOptions options = DeliveryOptions.defaults();
        
        public Builder address(Address address) { ... }
        public Builder window(DeliveryWindow window) { ... }
        public Builder options(DeliveryOptions options) { ... }
        public DeliveryRequest build() { ... }
    }
}
 
// Usage is now self-documenting:
scheduleDelivery(DeliveryRequest.builder("CUST123")
    .address(new Address("123 Main St", "Springfield", "62701"))
    .window(DeliveryWindow.afternoon(LocalDate.of(2024, 1, 15)))
    .options(DeliveryOptions.fragile().requiresSignature())
    .build());

Flag Parameters

Boolean parameters are particularly problematic: scheduleDelivery(..., true, false) tells readers nothing. Either use a parameter object with named fields, or split into multiple methods: scheduleFragileDelivery(), scheduleStandardDelivery().

Methods Working Together

Cohesive methods don't work in isolation—they collaborate to express the class's full capabilities. A well-designed class has methods that complement each other.

Patterns of Method Collaboration:

Public methods delegate to private helpers — High-level operations composed of low-level steps
Methods share and maintain invariants — All methods keep the object in a valid state
Template methods define structure — Base algorithm with customizable steps
Query methods support command methods — Commands use queries to make decisions
Factory methods produce valid objects — Used by other methods that need new instances

MethodCollaboration.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
61
62
63
64
65
66
67
68
69
70
71
72
public class ShoppingCart {
    private List<CartItem> items = new ArrayList<>();
    private DiscountStrategy discountStrategy;
    
    // PUBLIC API - High-level operations
    public void addProduct(Product product, int quantity) {
        validateQuantity(quantity);
        CartItem item = findExistingItem(product)
            .map(existing -> existing.addQuantity(quantity))
            .orElseGet(() -> createNewItem(product, quantity));
        
        if (!items.contains(item)) {
            items.add(item);
        }
        recalculateTotals();  // Maintain invariant
    }
    
    public OrderSummary checkout() {
        validateForCheckout();
        OrderSummary summary = buildOrderSummary();
        clear();  // Reset state
        return summary;
    }
    
    // QUERY METHODS - Used by commands
    public boolean isEmpty() {
        return items.isEmpty();
    }
    
    public int getTotalItemCount() {
        return items.stream().mapToInt(CartItem::getQuantity).sum();
    }
    
    // PRIVATE HELPERS - Support public methods
    private Optional<CartItem> findExistingItem(Product product) {
        return items.stream()
            .filter(item -> item.getProduct().equals(product))
            .findFirst();
    }
    
    private CartItem createNewItem(Product product, int quantity) {
        return new CartItem(product, quantity);
    }
    
    private void validateQuantity(int quantity) {
        if (quantity <= 0) {
            throw new IllegalArgumentException("Quantity must be positive");
        }
    }
    
    private void validateForCheckout() {
        if (isEmpty()) {
            throw new IllegalStateException("Cannot checkout empty cart");
        }
    }
    
    private void recalculateTotals() {
        // Called after any change to maintain consistency
    }
    
    private OrderSummary buildOrderSummary() {
        double subtotal = calculateSubtotal();
        double discount = discountStrategy.calculate(this);
        return new OrderSummary(items, subtotal, discount);
    }
    
    private double calculateSubtotal() {
        return items.stream()
            .mapToDouble(CartItem::getSubtotal)
            .sum();
    }
}

Method Ecosystem

Notice how the methods form an ecosystem: public methods for external use, private helpers for internal composition, query methods for state inspection, and validation methods for constraint enforcement. Each has its role, and together they express what a ShoppingCart can do.

Recognizing Incohesive Methods

Learning to spot incohesive methods is a critical skill. Here are common patterns and smells:

Method Cohesion Smells

•The Utility Dump: A method named 'processData' or 'handleRequest' that does unrelated operations based on input
•The God Method: A single method that runs hundreds of lines and orchestrates entire workflows
•The Flag-Driven Method: Behavior changes dramatically based on boolean flags (should be separate methods)
•The Setup-Act-Teardown Monster: A method that initializes, processes, and cleans up unrelated resources
•The Mixed Abstraction Level: Mixing business logic with I/O, database calls, and string formatting in one method
•The Orphan Logic: Code that doesn't use any other part of the method and could be extracted
•The Coincidental Grouping: Steps put together because they happen at the same time, not because they're conceptually related

IncohesionExamples.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
// SMELL: Flag-driven behavior
public void save(Entity entity, boolean validate, boolean notify) {
    if (validate) {
        // 20 lines of validation
    }
    // Save logic
    if (notify) {
        // 15 lines of notification
    }
}
// FIX: Separate methods, compose as needed
public void save(Entity entity) { /* save only */ }
public void saveWithValidation(Entity entity) { 
    validate(entity); 
    save(entity); 
}
public void saveAndNotify(Entity entity) { 
    save(entity); 
    notify(entity); 
}
 
// SMELL: Mixed abstraction levels  
public void processOrder(Order order) {
    // High level
    validateOrder(order);
    
    // Suddenly low level
    String sql = "INSERT INTO orders (id, customer_id) VALUES (?, ?)";
    PreparedStatement stmt = connection.prepareStatement(sql);
    stmt.setString(1, order.getId());
    // ... more JDBC code
    
    // Back to high level
    sendConfirmation(order);
}
// FIX: Keep abstraction consistent
public void processOrder(Order order) {
    validateOrder(order);
    orderRepository.save(order);  // Repository handles JDBC
    sendConfirmation(order);
}

Summary: Designing Cohesive Methods

We've explored the principles and practices of method cohesion. Let's consolidate:

Key Takeaways

•Cohesion is togetherness — Elements in a method should all contribute to one purpose.
•Single Responsibility applies to methods — Each method should have one reason to change.
•Length and complexity are signals — Long, complex methods need refactoring into focused pieces.
•Names reveal intent — Method names should describe why you'd call them, not just what they do.
•Parameter count matters — Many parameters suggest a method doing too much; use parameter objects.
•Methods collaborate — Well-designed methods work together, each playing its role in the class's purpose.
•Learn the smells — Recognize flag-driven methods, god methods, and mixed abstraction levels.

Module Complete:

You've now completed the Attributes and Methods module. You understand:

Attributes as the carriers of object state
Methods as the embodiment of object behavior
How to design meaningful attributes that serve your domain
How to design cohesive methods that work together harmoniously

With these foundations, you're ready to explore more advanced topics: constructors and object lifecycle, access modifiers, static vs instance members, and ultimately, how to design clean classes that embody these principles.

Module Complete

Congratulations! You've mastered the fundamental building blocks of classes: attributes and methods. You can now design classes with meaningful attributes and cohesive methods that create maintainable, understandable object-oriented systems.

4 / 4

Loading learning content...

System DesignClasses & Objects

Attributes and Methods

LevelBeginner

Duration60 mins

TopicClasses & Objects

4 / 4

Designing Cohesive Methods

The Harmony of Well-Designed Methods

What You Will Learn

What Is Cohesion?

At the method level, cohesion asks:

Does this method do one thing well?
Is everything in this method related to that one thing?
Does removing any line break the method's purpose?

At the class level, cohesion asks:

Do all methods operate on the same data?
Do methods support a single, focused responsibility?
Would any method make more sense in a different class?

Levels of Cohesion (from best to worst)
Cohesion Type	Description	Quality
Functional	All elements contribute to a single, well-defined task	Best ✓
Sequential	Output of one element feeds into the next	Good
Communicational	Elements operate on the same data	Acceptable
Procedural	Elements are grouped because they happen in sequence	Weak
Temporal	Elements are grouped because they execute at the same time	Weak
Logical	Elements are grouped by category but do different things	Poor
Coincidental	Elements have no meaningful relationship	Worst ✗

The Cohesion Test

Single Responsibility for Methods

The Single Responsibility Principle (SRP) applies not just to classes but to methods. Each method should have one reason to change—one focused purpose.

Signs a Method Has Multiple Responsibilities:

Long methods: More than 20-30 lines often indicates multiple tasks
Many parameters: Different parts of the method use different parameters
Multiple levels of abstraction: Mixing high-level logic with low-level details
Comment markers: // Step 1: Validate, // Step 2: Process, // Step 3: Save
Disconnected sections: Blank lines separating unrelated code blocks
Hard to name: The only accurate name includes 'and' or is vague like 'processData'

BeforeRefactoring.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
// BEFORE: Low cohesion - multiple responsibilities in one method
public void processOrder(Order order) {
    // Responsibility 1: Validation
    if (order.getItems().isEmpty()) {
        throw new ValidationException("Order must have items");
    }
    if (order.getCustomer() == null) {
        throw new ValidationException("Order must have a customer");
    }
    for (Item item : order.getItems()) {
        if (item.getQuantity() <= 0) {
            throw new ValidationException("Invalid quantity");
        }
    }
    
    // Responsibility 2: Pricing calculations
    double subtotal = 0;
    for (Item item : order.getItems()) {
        subtotal += item.getPrice() * item.getQuantity();
    }
    double tax = subtotal * 0.08;
    double shipping = calculateShipping(order);
    double total = subtotal + tax + shipping;
    order.setTotal(total);
    
    // Responsibility 3: Inventory update
    for (Item item : order.getItems()) {
        inventoryService.decrementStock(item.getProductId(), item.getQuantity());
    }
    
    // Responsibility 4: Persistence
    orderRepository.save(order);
    
    // Responsibility 5: Notification
    emailService.sendOrderConfirmation(order);
    
    // Responsibility 6: Analytics
    analyticsService.trackOrderPlaced(order);
}

AfterRefactoring.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
// AFTER: High cohesion - each method has one purpose
public void processOrder(Order order) {
    validate(order);
    calculatePricing(order);
    reserveInventory(order);
    save(order);
    notifyAndTrack(order);
}
 
private void validate(Order order) {
    orderValidator.validate(order);  // Dedicated validator
}
 
private void calculatePricing(Order order) {
    PricingResult pricing = pricingService.calculate(order);
    order.applyPricing(pricing);
}
 
private void reserveInventory(Order order) {
    inventoryService.reserve(order.getItems());
}
 
private void save(Order order) {
    orderRepository.save(order);
}
 
private void notifyAndTrack(Order order) {
    eventPublisher.publish(new OrderPlacedEvent(order));
    // Listeners handle email, analytics, etc.
}

Abstraction Levels

Method Length and Complexity

While there's no magic number, method length and complexity are strong signals of cohesion.

Guidelines for Method Length:

Ideal: 5-15 lines that fit on one screen
Acceptable: Up to 30 lines for complex algorithms
Concerning: 50+ lines (almost always needs refactoring)
Critical: 100+ lines (definitely needs refactoring)

Cyclomatic Complexity:

Cyclomatic complexity counts the number of independent paths through a method. Each if, else, for, while, case, catch, and &&/|| adds a path.

1-4: Simple, easy to test
5-7: Moderate complexity
8-10: High complexity, consider refactoring
11+: Very complex, hard to test and maintain

Signs of Excessive Complexity

•Deeply nested if/else blocks
•Multiple return statements scattered throughout
•Loops with complex exit conditions
•Many variables with overlapping scopes
•Hard to trace which path executes

Techniques to Reduce Complexity

•Extract conditional logic to methods
•Use guard clauses for early returns
•Replace conditionals with polymorphism
•Extract loops into well-named methods
•Use the Strategy pattern for variants

ReducingComplexity.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
// BEFORE: High complexity - many nesting levels
public double calculateDiscount(Customer customer, Order order) {
    double discount = 0;
    if (customer != null) {
        if (customer.getMembershipLevel() != null) {
            if (customer.getMembershipLevel() == MembershipLevel.GOLD) {
                discount = 0.15;
            } else if (customer.getMembershipLevel() == MembershipLevel.SILVER) {
                discount = 0.10;
            } else if (customer.getMembershipLevel() == MembershipLevel.BRONZE) {
                discount = 0.05;
            }
        }
        if (order.getTotal() > 100) {
            discount += 0.02;
        }
        if (isHolidaySeason()) {
            discount += 0.05;
        }
    }
    return discount;
}
 
// AFTER: Reduced complexity - guard clauses, extracted methods
public double calculateDiscount(Customer customer, Order order) {
    if (customer == null) return 0;  // Guard clause
    
    double discount = getMembershipDiscount(customer);
    discount += getLargeOrderDiscount(order);
    discount += getSeasonalDiscount();
    
    return discount;
}
 
private double getMembershipDiscount(Customer customer) {
    MembershipLevel level = customer.getMembershipLevel();
    if (level == null) return 0;
    
    return switch (level) {
        case GOLD -> 0.15;
        case SILVER -> 0.10;
        case BRONZE -> 0.05;
    };
}
 
private double getLargeOrderDiscount(Order order) {
    return order.getTotal() > 100 ? 0.02 : 0;
}
 
private double getSeasonalDiscount() {
    return isHolidaySeason() ? 0.05 : 0;
}

Method Naming

Method names are the primary documentation for what a method does. A well-named method doesn't need comments—its name explains its purpose.

Naming Principles:

Use verbs or verb phrases: Methods are actions (calculateTotal, sendEmail)
Be specific: sendOrderConfirmationEmail over send
Indicate what, not how: sortByDate over quickSortByDateField
Boolean methods read as questions: isValid, hasItems, canProceed
Use consistent vocabulary: If you use fetch for one retrieval, use it everywhere
Match method behavior to name: Don't name something getX if it modifies state

Method Naming Patterns
Pattern	Convention	Examples
Getters	getPropertyName()	getBalance(), getName(), getItems()
Setters	setPropertyName(value)	setBalance(amount), setStatus(status)
Boolean queries	isCondition(), hasProperty()	isActive(), isEmpty(), hasPermission()
Actions	verbNoun()	sendEmail(), createOrder(), deleteUser()
Conversions	toFormat(), asType()	toString(), toJson(), asList()
Computations	calculateX(), computeX()	calculateTotal(), computeHash()
Factory methods	createX(), of(), from()	createDefault(), of(value), fromString()
Finders	findByX(), getByX()	findByEmail(), getById()

Name Lies

The Intention-Revealing Name:

A method's name should reveal its intention—why you would call it, not just what it does.

Compare:

process(data) — Process how? Why would I call this?
calculateMonthlyPayment(loan) — Clear purpose, clear input

Compare:

handleEvent(event) — What does 'handle' mean?
updateInventoryOnPurchase(event) — Exactly what happens and when

Parameter Design for Cohesion

Method parameters significantly impact cohesion. Too many parameters often indicate a method doing too much.

Parameter Count Guidelines:

0 parameters: Ideal for getters and methods using only instance state
1-2 parameters: Comfortable, easy to use
3 parameters: Acceptable but consider alternatives
4+ parameters: Code smell; consider a parameter object

Why Many Parameters Hurt Cohesion:

Hard to remember parameter order
Easy to mix up similar-typed parameters
Suggests method does multiple things (different params for different parts)
Makes testing combinatorially complex

ParameterObjectPattern.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
// BEFORE: Too many parameters
public void scheduleDelivery(
    String customerId,
    String address,
    String city,
    String zipCode,
    LocalDate preferredDate,
    TimeSlot preferredTime,
    boolean requiresSignature,
    boolean isFragile,
    String specialInstructions
) {
    // Implementation
}
 
// AFTER: Parameter object encapsulates related data
public void scheduleDelivery(DeliveryRequest request) {
    // Implementation
}
 
public class DeliveryRequest {
    private final String customerId;
    private final Address address;  // Groups address components
    private final DeliveryWindow window;  // Groups date/time
    private final DeliveryOptions options;  // Groups flags
    
    // Builder pattern for flexible construction
    public static Builder builder(String customerId) {
        return new Builder(customerId);
    }
    
    public static class Builder {
        private String customerId;
        private Address address;
        private DeliveryWindow window;
        private DeliveryOptions options = DeliveryOptions.defaults();
        
        public Builder address(Address address) { ... }
        public Builder window(DeliveryWindow window) { ... }
        public Builder options(DeliveryOptions options) { ... }
        public DeliveryRequest build() { ... }
    }
}
 
// Usage is now self-documenting:
scheduleDelivery(DeliveryRequest.builder("CUST123")
    .address(new Address("123 Main St", "Springfield", "62701"))
    .window(DeliveryWindow.afternoon(LocalDate.of(2024, 1, 15)))
    .options(DeliveryOptions.fragile().requiresSignature())
    .build());

Flag Parameters

Methods Working Together

Cohesive methods don't work in isolation—they collaborate to express the class's full capabilities. A well-designed class has methods that complement each other.

Patterns of Method Collaboration:

Public methods delegate to private helpers — High-level operations composed of low-level steps
Methods share and maintain invariants — All methods keep the object in a valid state
Template methods define structure — Base algorithm with customizable steps
Query methods support command methods — Commands use queries to make decisions
Factory methods produce valid objects — Used by other methods that need new instances

MethodCollaboration.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
61
62
63
64
65
66
67
68
69
70
71
72
public class ShoppingCart {
    private List<CartItem> items = new ArrayList<>();
    private DiscountStrategy discountStrategy;
    
    // PUBLIC API - High-level operations
    public void addProduct(Product product, int quantity) {
        validateQuantity(quantity);
        CartItem item = findExistingItem(product)
            .map(existing -> existing.addQuantity(quantity))
            .orElseGet(() -> createNewItem(product, quantity));
        
        if (!items.contains(item)) {
            items.add(item);
        }
        recalculateTotals();  // Maintain invariant
    }
    
    public OrderSummary checkout() {
        validateForCheckout();
        OrderSummary summary = buildOrderSummary();
        clear();  // Reset state
        return summary;
    }
    
    // QUERY METHODS - Used by commands
    public boolean isEmpty() {
        return items.isEmpty();
    }
    
    public int getTotalItemCount() {
        return items.stream().mapToInt(CartItem::getQuantity).sum();
    }
    
    // PRIVATE HELPERS - Support public methods
    private Optional<CartItem> findExistingItem(Product product) {
        return items.stream()
            .filter(item -> item.getProduct().equals(product))
            .findFirst();
    }
    
    private CartItem createNewItem(Product product, int quantity) {
        return new CartItem(product, quantity);
    }
    
    private void validateQuantity(int quantity) {
        if (quantity <= 0) {
            throw new IllegalArgumentException("Quantity must be positive");
        }
    }
    
    private void validateForCheckout() {
        if (isEmpty()) {
            throw new IllegalStateException("Cannot checkout empty cart");
        }
    }
    
    private void recalculateTotals() {
        // Called after any change to maintain consistency
    }
    
    private OrderSummary buildOrderSummary() {
        double subtotal = calculateSubtotal();
        double discount = discountStrategy.calculate(this);
        return new OrderSummary(items, subtotal, discount);
    }
    
    private double calculateSubtotal() {
        return items.stream()
            .mapToDouble(CartItem::getSubtotal)
            .sum();
    }
}

Method Ecosystem

Recognizing Incohesive Methods

Learning to spot incohesive methods is a critical skill. Here are common patterns and smells:

Method Cohesion Smells

•The Utility Dump: A method named 'processData' or 'handleRequest' that does unrelated operations based on input
•The God Method: A single method that runs hundreds of lines and orchestrates entire workflows
•The Flag-Driven Method: Behavior changes dramatically based on boolean flags (should be separate methods)
•The Setup-Act-Teardown Monster: A method that initializes, processes, and cleans up unrelated resources
•The Mixed Abstraction Level: Mixing business logic with I/O, database calls, and string formatting in one method
•The Orphan Logic: Code that doesn't use any other part of the method and could be extracted
•The Coincidental Grouping: Steps put together because they happen at the same time, not because they're conceptually related

IncohesionExamples.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
// SMELL: Flag-driven behavior
public void save(Entity entity, boolean validate, boolean notify) {
    if (validate) {
        // 20 lines of validation
    }
    // Save logic
    if (notify) {
        // 15 lines of notification
    }
}
// FIX: Separate methods, compose as needed
public void save(Entity entity) { /* save only */ }
public void saveWithValidation(Entity entity) { 
    validate(entity); 
    save(entity); 
}
public void saveAndNotify(Entity entity) { 
    save(entity); 
    notify(entity); 
}
 
// SMELL: Mixed abstraction levels  
public void processOrder(Order order) {
    // High level
    validateOrder(order);
    
    // Suddenly low level
    String sql = "INSERT INTO orders (id, customer_id) VALUES (?, ?)";
    PreparedStatement stmt = connection.prepareStatement(sql);
    stmt.setString(1, order.getId());
    // ... more JDBC code
    
    // Back to high level
    sendConfirmation(order);
}
// FIX: Keep abstraction consistent
public void processOrder(Order order) {
    validateOrder(order);
    orderRepository.save(order);  // Repository handles JDBC
    sendConfirmation(order);
}

Summary: Designing Cohesive Methods

We've explored the principles and practices of method cohesion. Let's consolidate:

Key Takeaways

•Cohesion is togetherness — Elements in a method should all contribute to one purpose.
•Single Responsibility applies to methods — Each method should have one reason to change.
•Length and complexity are signals — Long, complex methods need refactoring into focused pieces.
•Names reveal intent — Method names should describe why you'd call them, not just what they do.
•Parameter count matters — Many parameters suggest a method doing too much; use parameter objects.
•Methods collaborate — Well-designed methods work together, each playing its role in the class's purpose.
•Learn the smells — Recognize flag-driven methods, god methods, and mixed abstraction levels.

Module Complete:

You've now completed the Attributes and Methods module. You understand:

Attributes as the carriers of object state
Methods as the embodiment of object behavior
How to design meaningful attributes that serve your domain
How to design cohesive methods that work together harmoniously

Module Complete

4 / 4