Code smells signal potential problems in your Java code, impacting maintainability, readability, and performance. While not always bugs, addressing them keeps your codebase clean and efficient. This article examines five common Java code smells, providing examples, explanations, and improved solutions.

1. Overly Long Methods

The Problem: Excessively long methods hinder readability, testing, and maintenance. Even with helper methods, combining multiple abstraction levels violates the Single Responsibility Principle (SRP).

Example:

public void processOrder(Order order) {
    validateOrder(order);
    calculateDiscount(order);
    updateInventory(order);
    generateInvoice(order);
    sendNotification(order);
}

processOrder mixes unrelated tasks (validation, discount calculation, inventory updates, invoicing, and notifications), making it hard to modify without unintended consequences.

Solution: Refactor into smaller, focused methods. Design patterns like the Command Pattern or Pipeline Pattern enhance modularity.

Refactored Code (Command Pattern):

interface OrderCommand { void execute(Order order); }

class ValidateOrderCommand implements OrderCommand {
    public void execute(Order order) { /* Validation logic */ }
}

// ... other commands (ApplyDiscountCommand, etc.)

class OrderProcessor {
    List<OrderCommand> commands;

    public OrderProcessor(List<OrderCommand> commands) { this.commands = commands; }

    public void processOrder(Order order) {
        for (OrderCommand command : commands) { command.execute(order); }
    }
}

// Usage
List<OrderCommand> commands = List.of(new ValidateOrderCommand(), new ApplyDiscountCommand(), ...);
OrderProcessor processor = new OrderProcessor(commands);
processor.processOrder(new Order());

Benefits: Improved modularity, independent testing and reuse of commands, easy addition of new steps.

2. God Classes

The Problem: A "God Class" handles too many responsibilities, leading to high coupling and poor maintainability.

Example:

public class OrderManager {
    public void createOrder() { /* Implementation */ }
    public void updateOrder() { /* Implementation */ }
    public void deleteOrder() { /* Implementation */ }
    public void validatePayment() { /* Implementation */ }
    public void sendInvoice() { /* Implementation */ }
}

Solution: Decouple responsibilities into smaller, focused classes.

Refactored Code:

public class OrderService {
    public void createOrder() { /* Implementation */ }
    // ... other order-related methods
}

public class PaymentService {
    public void validatePayment() { /* Implementation */ }
}

public class NotificationService {
    public void sendInvoice() { /* Implementation */ }
}

Benefits: Reduced coupling, improved modularity, easier maintenance, testing, and independent extension.

3. Magic Numbers

The Problem: Using literal numbers directly reduces code clarity and makes modifications risky.

Example:

public double calculateDiscount(double totalAmount) {
    return totalAmount > 1000 ? totalAmount * 0.1 : totalAmount;
}

Solution: Replace literal numbers with named constants.

Refactored Code:

private static final double DISCOUNT_THRESHOLD = 1000;
private static final double DISCOUNT_RATE = 0.1;

public double calculateDiscount(double totalAmount) {
    return totalAmount > DISCOUNT_THRESHOLD ? totalAmount * DISCOUNT_RATE : totalAmount;
}

Benefits: Enhanced readability, reduced error risk during updates, clearer business logic.

4. Duplicate Code

The Problem: Repeated code across methods or classes leads to inconsistencies and maintenance headaches.

Example:

public double calculateTax(double amount) { return amount * 0.18; }
public double calculateDiscount(double amount) { return amount * 0.1; }

Solution: Abstract common logic into a reusable method.

Refactored Code:

private double applyRate(double amount, double rate) { return amount * rate; }

public double calculateTax(double amount) { return applyRate(amount, 0.18); }
public double calculateDiscount(double amount) { return applyRate(amount, 0.1); }

Benefits: Eliminates redundancy, ensures consistency, simplifies modification and extension.

5. Excessive Parameter Lists

The Problem: Methods with many parameters are hard to read, understand, and prone to errors during calls.

Example:

public void processOrder(Order order) {
    validateOrder(order);
    calculateDiscount(order);
    updateInventory(order);
    generateInvoice(order);
    sendNotification(order);
}

Solution: Encapsulate parameters within an object or use a builder pattern.

Refactored Code:

interface OrderCommand { void execute(Order order); }

class ValidateOrderCommand implements OrderCommand {
    public void execute(Order order) { /* Validation logic */ }
}

// ... other commands (ApplyDiscountCommand, etc.)

class OrderProcessor {
    List<OrderCommand> commands;

    public OrderProcessor(List<OrderCommand> commands) { this.commands = commands; }

    public void processOrder(Order order) {
        for (OrderCommand command : commands) { command.execute(order); }
    }
}

// Usage
List<OrderCommand> commands = List.of(new ValidateOrderCommand(), new ApplyDiscountCommand(), ...);
OrderProcessor processor = new OrderProcessor(commands);
processor.processOrder(new Order());

Benefits: Improves readability and extensibility; adding parameters doesn't require method signature changes.

Addressing code smells proactively prevents larger design issues and reduces technical debt, leading to more robust and maintainable Java applications. Remember the principles of DRY (Don't Repeat Yourself) and SRP (Single Responsibility Principle) for cleaner, more efficient code.

The above is the detailed content of ommon Code Smells in Java and How to Fix Them. For more information, please follow other related articles on the PHP Chinese website!