CEN206 Object-Oriented Programming¶

Week-12 (Code Smells and Refactoring Fundamentals)¶

Spring Semester, 2025-2026¶

Download DOC-PDF, DOC-DOCX, SLIDE

Code Smells and Refactoring Fundamentals¶

Outline¶

• Module A: What is Refactoring? -- Definition, Clean Code, Technical Debt, When to Refactor, How to Refactor
• Module B: Bloaters -- Long Method, Large Class, Primitive Obsession, Long Parameter List, Data Clumps
• Module C: Object-Orientation Abusers -- Switch Statements, Temporary Field, Refused Bequest, Alternative Classes with Different Interfaces
• Module D: Change Preventers -- Divergent Change, Shotgun Surgery, Parallel Inheritance Hierarchies
• Module E: Dispensables -- Comments, Duplicate Code, Lazy Class, Data Class, Dead Code, Speculative Generality
• Module F: Couplers -- Feature Envy, Inappropriate Intimacy, Message Chains, Middle Man

Outline (Continued)¶

All 22 Code Smells Covered¶

Source: Refactoring.Guru -- Code Smells

Code Smell Categories (Overview)¶

Module A: What is Refactoring?¶

Definition, Clean Code, Technical Debt, When to Refactor, How to Refactor¶

Module A: What is Refactoring? -- Definition¶

Refactoring is a systematic process of improving the internal structure of code without changing its external behavior.

• The main purpose of refactoring is to fight technical debt
• It transforms messy, poorly designed code into clean, well-designed code
• Refactoring is not about fixing bugs or adding new features
• It is about making code easier to understand, maintain, and extend
• Think of it as applying a series of small behavior-preserving transformations

"Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which is too small to be worth doing. However the cumulative effect of each of these transformations is quite significant." -- Martin Fowler

Reference: RefactoringGuru -- What is Refactoring

Module A: Dirty Code vs. Clean Code¶

What is Dirty Code?¶

Dirty code is code that is hard to read, hard to change, and hard to maintain. It accumulates over time due to shortcuts, rushed deadlines, and lack of discipline.

What is Clean Code?¶

Clean code is the opposite -- it is obvious, maintainable, and a pleasure to work with.

"The main purpose of refactoring is to fight technical debt. It transforms a mess into clean code and simple design."

The Relationship¶

Dirty Code  --[refactoring]-->  Clean Code
     |                              |
     v                              v
  Hard to maintain            Easy to maintain
  Expensive to change         Cheap to change
  Full of hidden bugs         Bugs are visible

Module A: Clean Code Characteristics¶

Clean code has four key characteristics that distinguish it from dirty code:

1. Clean Code is Obvious for Other Programmers¶

• Poor variable names, bloated classes, and magic numbers make code sloppy and difficult to grasp
• Good code reads almost like well-written prose
• Other developers can understand it without extensive documentation

2. Clean Code Does Not Contain Duplication¶

• Each time you make a change in duplicated code, you must remember to make the same change in every instance
• Increases cognitive load and slows down progress
• Violates the DRY (Don't Repeat Yourself) principle

"Each time you have to make a change in a duplicate code, you have to remember to make the same change to every instance." -- RefactoringGuru

Module A: Clean Code Characteristics (Continued)¶

3. Clean Code Contains a Minimal Number of Classes and Moving Parts¶

• "Less code is less stuff to keep in your head"
• "Less code is less maintenance"
• Less code means fewer bugs
• Code is a liability, not an asset -- minimize it

4. Clean Code Passes All Tests¶

• Code that passes zero percent of tests is dirty code
• Code that is 95% clean but does not pass tests is still not clean enough
• Tests serve as a safety net for refactoring

The Bottom Line¶

"Clean code is easier and cheaper to maintain!"

• The majority of a software project's lifecycle is spent on maintenance
• Clean code reduces the cost of ongoing development
• New team members can ramp up faster

Reference: RefactoringGuru -- Clean Code

Module A: Technical Debt -- The Metaphor¶

What is Technical Debt?¶

Technical debt is a metaphor coined by Ward Cunningham. It compares quick-and-dirty coding decisions to financial debt:

• Taking on debt: You ship faster now by writing quick, dirty code
• Interest payments: Every time you work with dirty code, you spend extra time understanding and modifying it
• Bankruptcy: Eventually, the codebase becomes so messy that further development is nearly impossible

"You can temporarily speed up without writing tests for new features, but this will gradually slow your progress every day until you eventually pay off the debt by writing tests." -- RefactoringGuru

The Debt Spiral¶

Fast & Dirty Code  -->  Technical Debt Accumulates
       |                         |
       v                         v
  Ship Faster Now        Development Slows Down
       |                         |
       v                         v
  More Shortcuts         More Bugs, More Complexity
       |                         |
       v                         v
  Even More Debt    -->  Project May Become Unmaintainable

Reference: RefactoringGuru -- Technical Debt

Technical Debt Cycle (Diagram)¶

Module A: Causes of Technical Debt¶

Key Insight¶

• Everyone incurs technical debt from time to time
• The key is not to let it get out of hand
• Refactoring is the primary method of paying down technical debt

Module A: When to Refactor -- The Rule of Three¶

The Rule of Three is a simple heuristic for deciding when to refactor:

1. First Time -- Just Do It¶

• When you are doing something for the first time, just get it done
• Even if the code is not perfect, move forward

2. Second Time -- Wince at the Duplication¶

• When you do something similar for the second time, cringe at having to repeat yourself
• But do it anyway (for now)

3. Third Time -- Refactor¶

• When you do something for the third time, it is time to refactor
• Three strikes and you refactor!

"When you're doing something for the first time, just do it. The second time, you wince at the duplication but do it anyway. The third time, you refactor." -- RefactoringGuru

Reference: RefactoringGuru -- When to Refactor

Module A: When to Refactor -- Specific Situations¶

When Adding a Feature¶

Refactoring helps when adding features in two ways:

1. Understanding Other People's Code -- Refactoring the code to make it clearer helps you understand what is going on. "It's much easier to make changes in clean code."
2. Facilitating the Addition -- Sometimes the existing code structure makes it very difficult to add a new feature. Refactoring first can make the new feature much easier to implement.

When Fixing a Bug¶

• "Bugs in code behave just like those in real life: they live in the darkest, dirtiest places in the code."
• By cleaning problematic code first, errors become easier to identify and resolve
• Managers understand that bugs need fixing, so you can often bundle refactoring with bug fixes

During Code Review¶

• Code review is the last chance to tidy up code before it becomes available to the public
• Best performed in a pair: the reviewer proposes changes and the author implements them immediately
• Start with simple refactorings, tackle complex ones as follow-up tasks

Module A: How to Refactor -- The Core Principle¶

"Refactoring should be done as a series of small changes, each of which makes the existing code slightly better while still leaving the program in working order." -- RefactoringGuru

Working Code --> Small Change --> Still Working Code
     |                                   |
     v                                   v
  Test Pass                          Test Pass
     |                                   |
     v                                   v
Small Change --> Still Working Code --> Small Change ...

• Each individual refactoring is so small it is very unlikely to go wrong
• The system remains fully functional after each small step
• If something breaks, you know exactly which small change caused it

Reference: RefactoringGuru -- How to Refactor

Module A: The Refactoring Checklist¶

Before, during, and after refactoring, verify these three conditions:

1. The Code Should Become Cleaner¶

• If the code remains just as unclean after refactoring, you are wasting time
• Sometimes this happens when you mix multiple refactorings into one large change
• For severely problematic code, consider complete rewrites -- but only after writing tests and allocating sufficient time

2. New Functionality Should Not Be Created During Refactoring¶

• "Don't mix refactoring and direct development of new features"
• Keep refactoring and new features as separate commits for clarity and traceability

3. All Existing Tests Must Pass¶

• After refactoring, all existing tests should still pass
• Scenario 1: You made an error during refactoring -- fix the small error
• Scenario 2: The tests were too low-level (testing private methods rather than behavior) -- refactor the tests themselves or write higher-level BDD-style tests

Module A: Safe Refactoring Workflow¶

Step-by-Step Process¶

1. Ensure you have a comprehensive test suite for the code you want to refactor
2. Make one small change at a time
3. Run all tests after each change
4. If tests pass, move on to the next change
5. If tests fail, undo the change immediately and try a different approach
6. Commit frequently so you can easily revert if something goes wrong
7. Review the final result -- is the code cleaner?

Tools That Help¶

Refactoring Workflow (Diagram)¶

Module A: Takeaway¶

Key Points -- What is Refactoring?¶

• Refactoring = improving code structure without changing external behavior
• Clean code is obvious, duplication-free, minimal, tested, and maintainable
• Dirty code creates technical debt that slows future development
• Technical debt comes from business pressure, lack of tests, poor documentation, tightly coupled components, and more
• Use the Rule of Three: first time do it, second time cringe, third time refactor
• Refactor when adding features, fixing bugs, and during code reviews
• Make small, incremental changes and keep all tests passing
• Never mix refactoring and feature development in the same commit

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler

Module B: Bloaters¶

Code, Methods, and Classes That Have Grown So Large They Are Hard to Work With¶

Module B: Bloaters -- Overview¶

Bloaters are code, methods, and classes that have increased to such gargantuan proportions that they become hard to work with. Usually these smells do not crop up right away; rather, they accumulate over time as the program evolves (and especially when nobody makes an effort to eradicate them).

The 5 Bloater Smells¶

Reference: RefactoringGuru -- Bloaters

Module B: Bloater #1 -- Long Method¶

What Is It?¶

A method contains too many lines of code. Generally, any method longer than ten lines should make you start asking questions.

Signs and Symptoms¶

• The method has grown beyond 10-20 lines
• You need comments to explain what different sections of the method do
• The method name does not fully describe everything the method does
• There are deeply nested control structures

Reasons for the Problem¶

• It is mentally easier to add to an existing method than to create a new one
• "I'll just add these two lines here..." -- and it keeps growing
• Since it is harder to create a method than to add to one, most code is written as additions to existing methods
• The method originally started small but grew over time

Reference: RefactoringGuru -- Long Method

Long Method - Before (Code Smell)¶

Long Method - After (Refactored)¶

Module B: Bloater #1 -- Long Method (Java Example -- Before)¶

// SMELL: Long Method -- this method does too many things
public void processOrder(Order order) {
    // Validate order (10+ lines)
    if (order == null) throw new IllegalArgumentException("Order is null");
    if (order.getItems().isEmpty())
        throw new IllegalStateException("Order has no items");
    for (Item item : order.getItems()) {
        if (item.getQuantity() <= 0)
            throw new IllegalStateException("Invalid quantity");
        if (!inventory.isAvailable(item.getProductId(), item.getQuantity()))
            throw new IllegalStateException("Product not available");
    }

    // Calculate prices (10+ lines)
    double subtotal = 0;
    for (Item item : order.getItems()) {
        subtotal += item.getPrice() * item.getQuantity();
    }
    double tax = subtotal * 0.08;
    double shipping = subtotal > 100 ? 0 : 9.99;

    // Apply discounts (10+ lines)
    if (order.getCustomer().isLoyalMember()) {
        subtotal *= 0.90;
    }
    double total = subtotal + tax + shipping;

    // Update inventory, save order, send email... (20+ more lines)
}

Module B: Bloater #1 -- Long Method (Java Example -- After)¶

// REFACTORED: Extract Method applied
public void processOrder(Order order) {
    validateOrder(order);
    double subtotal = calculateSubtotal(order);
    double tax = calculateTax(subtotal);
    double shipping = calculateShipping(subtotal);
    subtotal = applyDiscounts(order, subtotal);
    double total = subtotal + tax + shipping;
    updateInventory(order);
    saveOrder(order, total);
    sendConfirmationEmail(order, total);
}

private void validateOrder(Order order) {
    if (order == null) throw new IllegalArgumentException("Order is null");
    if (order.getItems().isEmpty())
        throw new IllegalStateException("Order has no items");
    for (Item item : order.getItems()) {
        validateItem(item);
    }
}

private double calculateSubtotal(Order order) {
    return order.getItems().stream()
        .mapToDouble(item -> item.getPrice() * item.getQuantity())
        .sum();
}

Module B: Bloater #1 -- Long Method (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Among all types of object-oriented code, classes with short methods live longest
• The longer a method is, the harder it is to understand and maintain
• Long methods are a perfect hiding place for unwanted duplicate code
• Now that you have clear code, you are more likely to find truly effective performance optimizations

Module B: Bloater #2 -- Large Class¶

What Is It?¶

A class contains many fields, methods, and lines of code. Classes become bloated over time as programs grow.

Signs and Symptoms¶

• The class has too many fields (more than 5-10 that represent different concepts)
• The class has too many methods (covering multiple responsibilities)
• You cannot describe what the class does in one sentence without using "and"

Reasons for the Problem¶

• Classes usually start small but over time they get bloated as the program grows
• Programmers find it mentally less taxing to place a new feature in an existing class than to create a new class for the feature
• "This class already handles orders... I'll just add shipping logic here too"

Reference: RefactoringGuru -- Large Class

Large Class - Before (Code Smell)¶

Large Class - After (Refactored)¶

Module B: Bloater #2 -- Large Class (Java Example -- Before)¶

// SMELL: Large Class -- Order handles too many responsibilities
public class Order {
    // Customer fields
    private String customerName, customerEmail, customerPhone;
    // Shipping address fields
    private String shippingStreet, shippingCity, shippingState, shippingZip;
    // Billing address fields
    private String billingStreet, billingCity, billingState, billingZip;
    // Order fields
    private List<Item> items;
    private double subtotal, tax, shipping, discount, total;
    private Date orderDate, shipDate, deliveryDate;
    private String status, trackingNumber, paymentMethod;

    // Methods for ordering, shipping, billing, notifications, reporting...
    // 50+ methods covering multiple responsibilities
    public void addItem(Item item) { /* ... */ }
    public void calculateTotal() { /* ... */ }
    public void shipOrder() { /* ... */ }
    public void sendConfirmation() { /* ... */ }
    public void generateInvoice() { /* ... */ }
    public void updateCustomerProfile() { /* ... */ }
}

Module B: Bloater #2 -- Large Class (Java Example -- After)¶

// REFACTORED: Extract Class -- each class has a single responsibility
public class Order {
    private Customer customer;
    private ShippingAddress shippingAddress;
    private BillingAddress billingAddress;
    private List<Item> items;
    private OrderStatus status;

    public void addItem(Item item) { /* ... */ }
    public double calculateTotal() { /* ... */ }
}

public class Customer {
    private String name, email, phone;
    public void updateProfile() { /* ... */ }
}

public class ShippingAddress {
    private String street, city, state, zip;
}

public class BillingAddress {
    private String street, city, state, zip;
}

public class OrderShipper {
    public void shipOrder(Order order) { /* ... */ }
    public void sendConfirmation(Order order) { /* ... */ }
}

Module B: Bloater #2 -- Large Class (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Developers do not have to remember a large number of attributes for a class
• Splitting large classes frequently eliminates code duplication and redundant functionality
• Each class has one clear purpose (Single Responsibility Principle)
• Smaller classes are easier to test in isolation
• Smaller, focused classes can be reused in other contexts

Module B: Bloater #3 -- Primitive Obsession¶

What Is It?¶

The overuse of primitive types (int, String, double, boolean) instead of creating small objects for domain concepts.

Signs and Symptoms¶

• Use of primitives instead of small objects for simple tasks (such as currency, ranges, special strings for phone numbers, etc.)
• Use of constants for coding information (such as USER_ADMIN_ROLE = 1)
• Use of string constants as field names for use in data arrays

Reasons for the Problem¶

• Primitives are created "just to store a value" and eventually grow in usage
• Creating a field is easier than creating a whole new class
• "I'll just use a String for the phone number..."
• Primitives are often born from laziness: it seems simpler to use an int or String than to create a new class

Reference: RefactoringGuru -- Primitive Obsession

Module B: Bloater #3 -- Primitive Obsession (Java Example -- Before)¶

// SMELL: Primitive Obsession -- primitives everywhere
public class Employee {
    private String name;
    private String phoneNumber;        // Should be PhoneNumber object
    private int currencyAmount;        // Cents? Dollars? Euros?
    private String zipCode;            // Should validate format
    private int temperatureInFahrenheit;
    private String startDate;          // String for a date? Really?
    private int employeeType;          // 1=Engineer, 2=Salesman, 3=Manager
    private String socialSecurityNumber; // No validation!

    // Type code used in conditionals
    public double calculatePay() {
        if (employeeType == 1) {
            return baseSalary;
        } else if (employeeType == 2) {
            return baseSalary + commission;
        } else if (employeeType == 3) {
            return baseSalary + bonus;
        }
        return 0;
    }
}

Module B: Bloater #3 -- Primitive Obsession (Java Example -- After)¶

// REFACTORED: Replace Data Value with Object, Replace Type Code with Subclasses
public class PhoneNumber {
    private String areaCode;
    private String number;
    public PhoneNumber(String areaCode, String number) {
        validate(areaCode, number);
        this.areaCode = areaCode;
        this.number = number;
    }
    private void validate(String areaCode, String number) { /* ... */ }
    public String format() { return "(" + areaCode + ") " + number; }
}

public class Money {
    private long amountInCents;
    private Currency currency;
    public Money(long amountInCents, Currency currency) {
        this.amountInCents = amountInCents;
        this.currency = currency;
    }
    public Money add(Money other) { /* currency-safe addition */ }
}

// Type code replaced with polymorphism
abstract class Employee {
    abstract double calculatePay();
}
class Engineer extends Employee {
    double calculatePay() { return getBaseSalary(); }
}

Module B: Bloater #3 -- Primitive Obsession (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Code becomes more flexible thanks to use of objects instead of primitives
• Better understandability and organization of code
• Easier to find duplicate code that processes the same data
• Enables validation inside the value object (e.g., phone number format)

Module B: Bloater #4 -- Long Parameter List¶

What Is It?¶

A method has more than three or four parameters, making it hard to understand and use correctly.

Signs and Symptoms¶

• Method signatures that are too long to fit on one line
• Parameters that are hard to distinguish from each other
• Callers frequently pass wrong arguments in wrong positions

Reasons for the Problem¶

• A long parameter list may happen after several types of algorithms are merged in a single method
• A long list may have been created to control which algorithm will be run and how
• Long parameter lists can also result from efforts to make classes more independent of each other (instead of passing an object, individual values are passed)
• Long lists become "contradictory and hard to use as they grow longer"

Reference: RefactoringGuru -- Long Parameter List

Module B: Bloater #4 -- Long Parameter List (Java Example -- Before)¶

// SMELL: Long Parameter List -- 13 parameters!
public void createUser(String firstName, String lastName,
    String email, String phone, String street,
    String city, String state, String zipCode,
    String country, int age, String gender,
    boolean isActive, String role) {
    // ...
}

// Another example -- parameter values that could be calculated
public double calculateFinalPrice(
    int quantity, double itemPrice,
    double seasonalDiscount, double memberDiscount,
    double taxRate, double shippingCost,
    boolean applyPromo) {
    double base = quantity * itemPrice;
    double discount = base * (seasonalDiscount + memberDiscount);
    double tax = (base - discount) * taxRate;
    return base - discount + tax + shippingCost;
}

Module B: Bloater #4 -- Long Parameter List (Java Example -- After)¶

// REFACTORED: Introduce Parameter Object + Replace Parameter with Method Call
public class UserInfo {
    private String firstName, lastName, email, phone;
    private int age;
    private String gender;
    private boolean isActive;
    private String role;
    // constructor, getters...
}

public class Address {
    private String street, city, state, zipCode, country;
    // constructor, getters...
}

public void createUser(UserInfo userInfo, Address address) {
    // Clean, clear, and easy to understand
}

// Replace Parameter with Method Call
public double calculateFinalPrice(int quantity, double itemPrice) {
    double base = quantity * itemPrice;
    double discount = base * getSeasonalDiscount() + getMemberDiscount();
    double tax = (base - discount) * getTaxRate();
    return base - discount + tax + getShippingCost();
    // Method internally obtains values it needs
}

Module B: Bloater #4 -- Long Parameter List (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• More readable, shorter code
• Refactoring may reveal previously unnoticed duplicate code
• Method signatures become self-documenting

When to Ignore¶

• Do not create unwanted dependencies between classes just to reduce parameter count
• If the only connection between parameters is that they appear together in this method, introducing a parameter object may be premature

Module B: Bloater #5 -- Data Clumps¶

What Is It?¶

Identical groups of variables appear repeatedly across different parts of the code. These clumps should be turned into their own classes.

Signs and Symptoms¶

• The same group of fields appears in multiple classes (e.g., street, city, zipCode)
• The same group of parameters appears in multiple method signatures
• Removing one value from the group makes the rest meaningless

Reasons for the Problem¶

• Data clumps often appear when copy-pasting code
• Groups of data are passed around together but never formalized as a concept
• A good test: delete one of the data values -- do the rest still make sense? If not, it is a clump

Reference: RefactoringGuru -- Data Clumps

Module B: Bloater #5 -- Data Clumps (Java Example -- Before)¶

// SMELL: Data Clumps -- same three fields repeated everywhere
class Customer {
    private String street;
    private String city;
    private String zipCode;
    // other fields...
}

class Order {
    private String shippingStreet;
    private String shippingCity;
    private String shippingZipCode;
    // other fields...
}

class Warehouse {
    private String street;
    private String city;
    private String zipCode;
    // other fields...
}

// Same data clump in method signatures
void deliverOrder(String street, String city, String zipCode,
                  String recipientName) {
    // ...
}

Module B: Bloater #5 -- Data Clumps (Java Example -- After)¶

// REFACTORED: Extract Class -- Address encapsulates the data clump
public class Address {
    private String street;
    private String city;
    private String zipCode;

    public Address(String street, String city, String zipCode) {
        this.street = street;
        this.city = city;
        this.zipCode = zipCode;
    }

    public String format() {
        return street + ", " + city + " " + zipCode;
    }
    // getters, equals, hashCode...
}

class Customer { private Address address; }
class Order { private Address shippingAddress; }
class Warehouse { private Address address; }

// Clean method signature using Introduce Parameter Object
void deliverOrder(Address deliveryAddress, String recipientName) {
    // ...
}

Module B: Bloater #5 -- Data Clumps (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Improves understanding and organization of code
• Reduces code size by eliminating repeated field groups
• Operations associated with the data can be moved into the new class (e.g., address formatting, validation)

When to Ignore¶

• Passing complete objects as parameters may create unwanted dependencies between classes
• If the data group only appears together in two places, the overhead of a new class may not be worth it

Module B: Takeaway¶

Key Points -- Bloaters¶

Common Thread¶

All bloaters grow gradually over time. No one writes a 200-line method on purpose on day one. Vigilance and regular refactoring prevent bloaters from taking hold.

"If you feel the need to comment something inside a method, you should take that code and put it into a new method. Even a single line can and should be broken out into a separate method if it requires explanation." -- Martin Fowler

Module C: Object-Orientation Abusers¶

Incomplete or Incorrect Application of Object-Oriented Programming Principles¶

Module C: Object-Orientation Abusers -- Overview¶

Object-Orientation Abusers are cases where object-oriented programming principles are applied incompletely or incorrectly.

The 4 OO Abuser Smells¶

All these smells represent incomplete or incorrect applications of OOP principles.

Reference: RefactoringGuru -- OO Abusers

Module C: OO Abuser #1 -- Switch Statements¶

What Is It?¶

You have a complex switch operator or sequence of if statements that performs different actions based on a type or condition.

Signs and Symptoms¶

• A complex switch or if-else chain that tests the same condition in multiple places
• The same switch structure is likely duplicated everywhere the type is handled
• Adding a new type requires modifying every switch statement

Reasons for the Problem¶

• Relatively rare use of switch and case is one of the hallmarks of object-oriented code
• Often a switch is scattered in different places in the program
• When a new condition is added, you have to find all the switch code and modify it
• As a rule of thumb, when you see a switch you should think of polymorphism

Reference: RefactoringGuru -- Switch Statements

Switch Statements - Before (Code Smell)¶

Switch Statements - After (Refactored)¶

Module C: OO Abuser #1 -- Switch Statements (Java Example -- Before)¶

// SMELL: Switch Statements -- duplicated conditional logic
public class PayrollCalculator {

    public double calculatePay(Employee employee) {
        switch (employee.getType()) {
            case ENGINEER:
                return employee.getMonthlySalary();
            case SALESMAN:
                return employee.getMonthlySalary()
                       + employee.getCommission();
            case MANAGER:
                return employee.getMonthlySalary()
                       + employee.getBonus();
            default:
                throw new RuntimeException("Invalid employee type");
        }
    }

    // Same switch duplicated in another method!
    public int calculateVacationDays(Employee employee) {
        switch (employee.getType()) {
            case ENGINEER:  return 15;
            case SALESMAN:  return 12;
            case MANAGER:   return 20;
            default: throw new RuntimeException("Invalid type");
        }
    }
}

Module C: OO Abuser #1 -- Switch Statements (Java Example -- After)¶

// REFACTORED: Replace Conditional with Polymorphism
public abstract class Employee {
    private double monthlySalary;

    public abstract double calculatePay();
    public abstract int getVacationDays();

    public double getMonthlySalary() { return monthlySalary; }
}

public class Engineer extends Employee {
    public double calculatePay() { return getMonthlySalary(); }
    public int getVacationDays() { return 15; }
}

public class Salesman extends Employee {
    private double commission;
    public double calculatePay() {
        return getMonthlySalary() + commission;
    }
    public int getVacationDays() { return 12; }
}

public class Manager extends Employee {
    private double bonus;
    public double calculatePay() {
        return getMonthlySalary() + bonus;
    }
    public int getVacationDays() { return 20; }
}

Module C: OO Abuser #1 -- Switch Statements (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Improved code organization through polymorphism
• Easier to add new types -- just add a new subclass (Open/Closed Principle)
• Eliminates duplicated conditional logic scattered throughout the codebase

When to Ignore¶

• When a switch performs simple actions and appears in only one place
• Simple factory methods (Factory Method or Abstract Factory patterns) are often acceptable
• If the switch is unlikely to change, polymorphism may be overkill

Module C: OO Abuser #2 -- Temporary Field¶

What Is It?¶

Temporary fields get their values (and thus are needed by objects) only under certain circumstances. Outside of these circumstances, they are empty or contain irrelevant data.

Signs and Symptoms¶

• Object fields that are only populated and used during specific algorithm execution
• Fields that are null or empty most of the time
• You expect to see data in fields that are almost always empty

Reasons for the Problem¶

• Often temporary fields are created for use in an algorithm that requires a large amount of inputs
• Instead of creating many parameters in the method, the programmer decides to create fields for this data in the class
• These fields are used only in the algorithm and are useless the rest of the time
• This code is hard to understand because you expect object fields to consistently contain meaningful data

Reference: RefactoringGuru -- Temporary Field

Module C: OO Abuser #2 -- Temporary Field (Java Example -- Before)¶

// SMELL: Temporary Field -- fields meaningful only during checkout
public class Order {
    private List<Item> items;
    private Customer customer;

    // These fields are only used during checkout!
    private double taxRate;          // Only set during checkout
    private String promoCode;        // Only set when applying discount
    private double shippingWeight;   // Only relevant for physical items
    private String shippingMethod;   // Empty until shipping is selected

    public double checkout() {
        // Uses taxRate, promoCode, shippingWeight, shippingMethod
        // These are confusing when order is not in checkout phase
        double subtotal = calculateSubtotal();
        double discount = promoCode != null ? applyPromo(promoCode) : 0;
        double tax = subtotal * taxRate;
        double shipping = calculateShipping(shippingWeight, shippingMethod);
        return subtotal - discount + tax + shipping;
    }
}

Module C: OO Abuser #2 -- Temporary Field (Java Example -- After)¶

// REFACTORED: Extract Class -- separate checkout context
public class Order {
    private List<Item> items;
    private Customer customer;

    public double calculateSubtotal() {
        return items.stream()
            .mapToDouble(item -> item.getPrice() * item.getQuantity())
            .sum();
    }
}

public class CheckoutContext {
    private double taxRate;
    private String promoCode;
    private double shippingWeight;
    private String shippingMethod;

    public CheckoutContext(double taxRate, String promoCode,
                           double shippingWeight, String shippingMethod) {
        this.taxRate = taxRate;
        this.promoCode = promoCode;
        this.shippingWeight = shippingWeight;
        this.shippingMethod = shippingMethod;
    }

    public double calculateFinalPrice(Order order) {
        double subtotal = order.calculateSubtotal();
        double discount = promoCode != null ? applyPromo(promoCode, subtotal) : 0;
        double tax = subtotal * taxRate;
        double shipping = calculateShipping(shippingWeight, shippingMethod);
        return subtotal - discount + tax + shipping;
    }
}

Module C: OO Abuser #2 -- Temporary Field (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Better code clarity and organization -- no more confusion about when fields have meaningful values
• All fields in a class are always meaningful
• Code becomes easier to reason about

When to Ignore¶

• If the temporary state is truly transient and clearly documented
• If the algorithm is simple enough that the temporary fields do not cause confusion

Module C: OO Abuser #3 -- Refused Bequest¶

What Is It?¶

If a subclass uses only some of the methods and properties inherited from its parents, the hierarchy is off-kilter. The unneeded methods may simply go unused or be redefined to throw exceptions.

Signs and Symptoms¶

• A subclass overrides parent methods to throw UnsupportedOperationException
• A subclass leaves most inherited methods unused
• The inheritance relationship does not model a true "is-a" relationship

Reasons for the Problem¶

• Someone was motivated to create inheritance between classes only by the desire to reuse code in a superclass
• But the superclass and subclass are completely different in nature
• Like making Dog extend Chair because both have four legs

Reference: RefactoringGuru -- Refused Bequest

Module C: OO Abuser #3 -- Refused Bequest (Java Example -- Before)¶

// SMELL: Refused Bequest -- Dog inherits fly() it cannot use
public class Animal {
    public void walk() { /* walking logic */ }
    public void fly()  { /* flying logic */ }
    public void swim() { /* swimming logic */ }
    public void eat()  { /* eating logic */ }
}

public class Dog extends Animal {
    // Dog can walk, swim, and eat -- but NOT fly
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Dogs can't fly!");
    }
}

public class Fish extends Animal {
    // Fish can swim and eat -- but NOT walk or fly
    @Override
    public void walk() {
        throw new UnsupportedOperationException("Fish can't walk!");
    }
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Fish can't fly!");
    }
}

Module C: OO Abuser #3 -- Refused Bequest (Java Example -- After)¶

// REFACTORED: Extract Superclass + Replace Inheritance with Delegation
public abstract class Animal {
    public abstract void eat();
}

public interface Walkable { void walk(); }
public interface Swimmable { void swim(); }
public interface Flyable { void fly(); }

public class Dog extends Animal implements Walkable, Swimmable {
    public void eat()  { /* eating logic */ }
    public void walk() { /* walking logic */ }
    public void swim() { /* swimming logic */ }
    // No fly() method -- dogs don't fly!
}

public class Eagle extends Animal implements Walkable, Flyable {
    public void eat()  { /* eating logic */ }
    public void walk() { /* walking logic */ }
    public void fly()  { /* flying logic */ }
}

public class Fish extends Animal implements Swimmable {
    public void eat()  { /* eating logic */ }
    public void swim() { /* swimming logic */ }
}

Module C: OO Abuser #3 -- Refused Bequest (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Improves code clarity and organization
• Eliminates confusing or meaningless inheritance hierarchies
• Adheres to the Liskov Substitution Principle (a subtype should be substitutable for its parent type)
• No more methods that throw UnsupportedOperationException

When to Ignore¶

• If the refused bequest is minimal and does not cause confusion
• If reuse through inheritance provides significant benefits and the refused methods are clearly documented

Module C: OO Abuser #4 -- Alternative Classes with Different Interfaces¶

What Is It?¶

Two classes perform identical functions but have different method names. They should share a common interface.

Signs and Symptoms¶

• Two classes that do the same thing but with different method names
• Client code uses if-else to choose between the two classes
• The classes cannot be used interchangeably

Reasons for the Problem¶

• The developer who created one class probably did not know that a functionally equivalent class already existed
• Or they created it independently and did not think to unify the interfaces

Reference: RefactoringGuru -- Alternative Classes with Different Interfaces

Module C: OO Abuser #4 -- Alternative Classes (Java Example -- Before)¶

// SMELL: Alternative Classes with Different Interfaces
public class EmailNotifier {
    public void sendEmail(String to, String subject, String body) {
        // sends email notification
    }
}

public class SMSNotifier {
    public void dispatchSMS(String phoneNumber, String message) {
        // sends SMS notification
    }
}

// Client code has to know the specific interface of each
public class NotificationService {
    public void notifyUser(User user, String message) {
        if (user.prefersEmail()) {
            EmailNotifier emailer = new EmailNotifier();
            emailer.sendEmail(user.getEmail(), "Notification", message);
        } else {
            SMSNotifier sms = new SMSNotifier();
            sms.dispatchSMS(user.getPhone(), message);
        }
    }
}

Module C: OO Abuser #4 -- Alternative Classes (Java Example -- After)¶

// REFACTORED: Extract Superclass / common interface
public interface Notifier {
    void send(String recipient, String message);
}

public class EmailNotifier implements Notifier {
    @Override
    public void send(String recipient, String message) {
        // sends email notification to 'recipient' (email address)
    }
}

public class SMSNotifier implements Notifier {
    @Override
    public void send(String recipient, String message) {
        // sends SMS notification to 'recipient' (phone number)
    }
}

// Client code uses the common interface -- polymorphism!
public class NotificationService {
    public void notifyUser(User user, String message) {
        Notifier notifier = user.prefersEmail()
            ? new EmailNotifier()
            : new SMSNotifier();
        notifier.send(user.getContactInfo(), message);
    }
}

Module C: OO Abuser #4 -- Alternative Classes (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Eliminates unnecessary duplicated code, making the code lighter
• Code becomes more readable and understandable through a unified interface
• Enables polymorphism -- clients can use the common interface interchangeably

When to Ignore¶

• Sometimes merging classes is impossible, such as when the alternative classes are in different libraries each with their own versioning

Module C: Takeaway¶

Key Points -- Object-Orientation Abusers¶

Common Thread¶

All OO Abusers stem from misunderstanding or misapplying OOP principles. The fix is almost always: use polymorphism correctly, prefer composition over inheritance when appropriate, and design clean interfaces.

"When you see a switch statement, think polymorphism." -- RefactoringGuru

Module D: Change Preventers¶

Smells That Make Changing Code Disproportionately Difficult¶

Module D: Change Preventers -- Overview¶

Change Preventers are smells that mean if you need to change something in one place in your code, you have to make many changes in other places too. Program development becomes much more expensive and complex as a result.

The 3 Change Preventer Smells¶

These smells are opposites in some ways: Divergent Change is one class suffering many changes, while Shotgun Surgery is one change affecting many classes.

Reference: RefactoringGuru -- Change Preventers

Module D: Change Preventer #1 -- Divergent Change¶

What Is It?¶

You find yourself having to change many unrelated methods when you make changes to a class. For example, when adding a new product type, you have to change the methods for finding, displaying, and ordering products.

Signs and Symptoms¶

• A class requires frequent modifications for different, unrelated reasons
• One class has accumulated responsibilities that should belong to different classes
• The class violates the Single Responsibility Principle

Reasons for the Problem¶

• These scattered modifications typically stem from poor program structure or copy-paste programming
• A class has gradually absorbed multiple responsibilities over time
• "This is the Order class -- I'll just add the display logic here too"

Reference: RefactoringGuru -- Divergent Change

Divergent Change (Diagram)¶

Module D: Change Preventer #1 -- Divergent Change (Java Example -- Before)¶

// SMELL: Divergent Change -- one class, many reasons to change
public class Order {
    private List<Item> items;
    private Customer customer;

    // Changes when product types change
    public void addProduct(Product p) { /* ... */ }

    // Changes when display format changes
    public String formatForDisplay() {
        return "Order: " + items.toString(); // HTML? JSON? XML?
    }

    // Changes when database schema changes
    public void saveToDatabase(Connection conn) {
        String sql = "INSERT INTO orders ...";
        // JDBC code here
    }

    // Changes when shipping rules change
    public double calculateShipping() {
        if (getTotalWeight() > 50) return 15.99;
        return 5.99;
    }

    // Changes when notification requirements change
    public void sendConfirmation() {
        // email sending logic
    }
}

Module D: Change Preventer #1 -- Divergent Change (Java Example -- After)¶

// REFACTORED: Extract Class -- each class has a single reason to change
public class Order {
    private List<Item> items;
    private Customer customer;
    public void addProduct(Product p) { /* ... */ }
    public List<Item> getItems() { return items; }
}

public class OrderFormatter {
    public String formatForDisplay(Order order) {
        return "Order: " + order.getItems().toString();
    }
    public String formatAsJson(Order order) { /* ... */ }
}

public class OrderRepository {
    public void save(Order order) { /* database logic */ }
    public Order findById(int id) { /* database logic */ }
}

public class ShippingCalculator {
    public double calculateShipping(Order order) { /* shipping rules */ }
}

public class OrderNotifier {
    public void sendConfirmation(Order order) { /* email logic */ }
}

Module D: Change Preventer #1 -- Divergent Change (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Improves code organization -- each class changes for exactly one reason
• Reduces code duplication across the codebase
• Simplifies support and maintenance -- changes are localized
• Follows the Single Responsibility Principle (SRP)

Divergent Change vs. Shotgun Surgery¶

Module D: Change Preventer #2 -- Shotgun Surgery¶

What Is It?¶

Making any modification requires you to make many small changes to many different classes.

Signs and Symptoms¶

• A single logical change (adding a field, changing a rule) requires touching 5+ classes
• You often forget to make a change in one of the scattered locations
• The scattered classes all deal with the same concern

Reasons for the Problem¶

• A single responsibility has been split up among a large number of classes
• This can happen after overzealous application of Divergent Change refactoring -- splitting a class too aggressively
• Incremental development where related code ended up in different places

Reference: RefactoringGuru -- Shotgun Surgery

Shotgun Surgery (Diagram)¶

Module D: Change Preventer #2 -- Shotgun Surgery (Java Example -- Before)¶

// SMELL: Shotgun Surgery -- adding a "phone" field requires 7+ file changes!
public class Customer {
    private String name;
    private String email;
    // Adding "phone" requires changes in ALL of these classes:
}

public class CustomerValidator {
    public void validate(Customer c) {
        if (c.getName() == null) throw new ValidationException("Name required");
        if (c.getEmail() == null) throw new ValidationException("Email required");
        // Must add phone validation here too
    }
}

public class CustomerRepository {
    public void save(Customer c) {
        String sql = "INSERT INTO customers (name, email) VALUES (?, ?)";
        // Must update SQL to include phone
    }
}

public class CustomerDTO { /* Must add phone */ }
public class CustomerMapper { /* Must update mapping */ }
public class CustomerView { /* Must update UI */ }
public class CustomerTest { /* Must update tests */ }
// 7+ files changed for ONE small addition!

Module D: Change Preventer #2 -- Shotgun Surgery (Java Example -- After)¶

// REFACTORED: Consolidate responsibility -- Move Method + Move Field
public class Customer {
    private String name;
    private String email;
    private String phone; // New field -- only one class to change!

    public void validate() {
        if (name == null) throw new ValidationException("Name required");
        if (email == null) throw new ValidationException("Email required");
        if (phone == null) throw new ValidationException("Phone required");
    }

    public CustomerDTO toDTO() {
        return new CustomerDTO(name, email, phone);
    }
}

public class CustomerRepository {
    public void save(Customer c) {
        c.validate(); // Customer validates itself
        // Single place for persistence logic
    }
}

// Eliminated: CustomerValidator (inlined into Customer)
// Eliminated: CustomerMapper (inlined into Customer.toDTO())

Module D: Change Preventer #2 -- Shotgun Surgery (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Better code organization -- related logic lives together
• Less code duplication across the codebase
• Easier maintenance -- changes are localized to fewer files
• Reduces the risk of missing a change in one of many scattered locations

When to Ignore¶

• Some frameworks (Spring, Jakarta EE) intentionally separate concerns into layers (Controller, Service, Repository)
• In these cases, shotgun surgery may be an acceptable tradeoff for architectural clarity

Module D: Change Preventer #3 -- Parallel Inheritance Hierarchies¶

What Is It?¶

Whenever you create a subclass for a class, you find yourself needing to create a subclass for another class as well.

Signs and Symptoms¶

• Two class hierarchies grow in lockstep
• Adding a class in one hierarchy always requires adding a class in the other
• Class prefixes from one hierarchy mirror prefixes in another (e.g., Circle/CircleRenderer)

Reasons for the Problem¶

• Initially manageable class structures become increasingly difficult to modify as new classes are added
• The parallel may have been so small nobody noticed at first
• This smell is actually a special case of Shotgun Surgery

Reference: RefactoringGuru -- Parallel Inheritance Hierarchies

Module D: Change Preventer #3 -- Parallel Inheritance (Java Example -- Before)¶

// SMELL: Parallel Inheritance Hierarchies
// Every time you add a new shape, you must also add a new renderer
public abstract class Shape {
    abstract double area();
}
public class Circle extends Shape {
    double area() { return Math.PI * radius * radius; }
}
public class Rectangle extends Shape {
    double area() { return width * height; }
}
public class Triangle extends Shape {
    double area() { return 0.5 * base * height; }
}

// Parallel hierarchy -- grows in lockstep!
public abstract class ShapeRenderer {
    abstract void render(Shape shape);
}
public class CircleRenderer extends ShapeRenderer {
    void render(Shape shape) { /* draw circle */ }
}
public class RectangleRenderer extends ShapeRenderer {
    void render(Shape shape) { /* draw rectangle */ }
}
public class TriangleRenderer extends ShapeRenderer {
    void render(Shape shape) { /* draw triangle */ }
}
// Add Pentagon? Must add PentagonRenderer too!

Module D: Change Preventer #3 -- Parallel Inheritance (Java Example -- After)¶

// REFACTORED: Move Method + Move Field -- merge hierarchies
public abstract class Shape {
    abstract double area();
    abstract void render(); // Rendering logic moved INTO the shape
}

public class Circle extends Shape {
    private double radius;

    double area() { return Math.PI * radius * radius; }

    void render() {
        // Circle rendering logic (formerly in CircleRenderer)
        System.out.println("Drawing circle with radius " + radius);
    }
}

public class Rectangle extends Shape {
    private double width, height;

    double area() { return width * height; }

    void render() {
        // Rectangle rendering logic (formerly in RectangleRenderer)
        System.out.println("Drawing rectangle " + width + "x" + height);
    }
}
// No more parallel ShapeRenderer hierarchy!
// Adding Pentagon requires changes in ONE hierarchy only

Module D: Change Preventer #3 -- Parallel Inheritance (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Reduces code duplication across related hierarchies
• Improves overall code organization and maintainability
• Adding a new type requires changes in one hierarchy instead of two

When to Ignore¶

• Sometimes having parallel class hierarchies is a way of avoiding even bigger design problems
• If they provide clear separation of concerns (e.g., rendering vs. business logic), they may be justified
• If refactoring attempts produce uglier code, it may be wiser to accept the current structure

Module D: Takeaway¶

Key Points -- Change Preventers¶

Common Thread¶

Change Preventers make software rigid -- they resist change by requiring disproportionate effort for simple modifications. The fixes involve reorganizing responsibilities so that changes are localized.

"The art of refactoring is knowing which smells indicate an opportunity for improvement and which are acceptable trade-offs." -- Martin Fowler

Module E: Dispensables¶

Something Pointless and Unneeded Whose Absence Would Make Code Cleaner¶

Module E: Dispensables -- Overview¶

A dispensable is something pointless and unneeded whose absence would make the code cleaner, more efficient, and easier to understand.

The 6 Dispensable Smells¶

Reference: RefactoringGuru -- Dispensables

Module E: Dispensable #1 -- Comments¶

What Is It?¶

A method is filled with explanatory comments that attempt to explain what the code does. The best comment is a good name for a method or class.

Signs and Symptoms¶

• Large comment blocks explaining what the next few lines do
• Comments that restate the code in English
• Comments used as "deodorant" trying to mask the smell of bad code
• Outdated comments that no longer match the code

Reasons for the Problem¶

• Comments are usually created with the best of intentions when the author realizes code is not intuitive
• The comment acts as a deodorant trying to mask the smell of bad code
• If you feel that a code fragment cannot be understood without comments, try to change the code structure so that comments become unnecessary

Reference: RefactoringGuru -- Comments

Module E: Dispensable #1 -- Comments (Java Example -- Before)¶

// SMELL: Comments -- code needs excessive explanation
public class PricingEngine {

    public double calculateDiscount(Customer customer, double price) {
        // Check if the customer is eligible for a premium discount
        // by verifying their membership status and purchase history.
        // A customer qualifies if they have been a member for more
        // than 2 years AND have made purchases totaling at least $1000
        // AND their account status is active.
        if ((customer.getMembershipYears() > 2) &&
            (customer.getTotalPurchases() >= 1000.0) &&
            (customer.getStatus().equals("ACTIVE"))) {
            // Apply the premium discount rate of 15%
            // This was changed from 10% in Q3 2024
            return price * 0.15;
        }
        // Apply standard discount rate of 5% for non-premium customers
        return price * 0.05;
    }
}

Module E: Dispensable #1 -- Comments (Java Example -- After)¶

// REFACTORED: Extract Method + Extract Variable -- self-documenting code
public class PricingEngine {

    private static final double PREMIUM_DISCOUNT_RATE = 0.15;
    private static final double STANDARD_DISCOUNT_RATE = 0.05;

    public double calculateDiscount(Customer customer, double price) {
        if (customer.isEligibleForPremiumDiscount()) {
            return price * PREMIUM_DISCOUNT_RATE;
        }
        return price * STANDARD_DISCOUNT_RATE;
    }
}

// In Customer class:
public class Customer {
    private static final int MIN_MEMBERSHIP_YEARS = 2;
    private static final double MIN_PURCHASE_AMOUNT = 1000.0;

    public boolean isEligibleForPremiumDiscount() {
        return getMembershipYears() > MIN_MEMBERSHIP_YEARS
            && getTotalPurchases() >= MIN_PURCHASE_AMOUNT
            && isActive();
    }

    public boolean isActive() {
        return "ACTIVE".equals(status);
    }
}

Module E: Dispensable #1 -- Comments (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• Code becomes more self-explanatory and intuitive
• Eliminates the risk of outdated or misleading comments
• Reduces maintenance burden (no need to update comments when code changes)

When to Ignore¶

• Explaining WHY something is done: // Using insertion sort because array is nearly sorted
• Warning of consequences: // WARNING: Changing this order breaks the payment pipeline
• TODO comments: // TODO: Replace with async call after API v2 migration
• Javadoc for public APIs: Documenting parameters, return values, exceptions

Module E: Dispensable #2 -- Duplicate Code¶

What Is It?¶

Two code fragments look almost identical. This is one of the most common code smells.

Signs and Symptoms¶

• The same code structure appears in multiple places with minor variations
• Copy-pasted code with small modifications
• Two methods that do essentially the same thing with different variable names

Reasons for the Problem¶

• Multiple programmers working simultaneously write similar solutions independently
• Copy-paste programming under time pressure and deadline rushing
• Subtle duplication where code looks different but performs identical operations
• Developer laziness or inability to refactor existing "almost right" code

Reference: RefactoringGuru -- Duplicate Code

Module E: Dispensable #2 -- Duplicate Code (Java Example -- Before)¶

// SMELL: Duplicate Code -- same logic in two methods
public class ReportGenerator {

    public void printOwing() {
        // Print banner (DUPLICATED)
        System.out.println("***********************");
        System.out.println("*** Customer Owes ***");
        System.out.println("***********************");

        // Calculate outstanding (DUPLICATED)
        double outstanding = 0.0;
        for (Order order : orders) {
            outstanding += order.getAmount();
        }
        System.out.println("Amount: " + outstanding);
    }

    public void printStatement() {
        // Print banner (DUPLICATED)
        System.out.println("***********************");
        System.out.println("*** Customer Owes ***");
        System.out.println("***********************");

        // Calculate outstanding (DUPLICATED)
        double outstanding = 0.0;
        for (Order order : orders) {
            outstanding += order.getAmount();
        }
        // ... additional statement logic
    }
}

Module E: Dispensable #2 -- Duplicate Code (Java Example -- After)¶

// REFACTORED: Extract Method -- duplicated code consolidated
public class ReportGenerator {

    private void printBanner() {
        System.out.println("***********************");
        System.out.println("*** Customer Owes ***");
        System.out.println("***********************");
    }

    private double calculateOutstanding() {
        return orders.stream()
            .mapToDouble(Order::getAmount)
            .sum();
    }

    public void printOwing() {
        printBanner();
        double outstanding = calculateOutstanding();
        System.out.println("Amount: " + outstanding);
    }

    public void printStatement() {
        printBanner();
        double outstanding = calculateOutstanding();
        // ... additional statement logic
    }
}

Module E: Dispensable #2 -- Duplicate Code (Treatment & Payoff)¶

Treatment (Refactoring Techniques)¶

Payoff¶

• "Merging duplicate code simplifies the structure of your code and makes it shorter"
• Bug fixes only need to be applied once instead of in multiple places
• Code that is easier to understand and cheaper to maintain

When to Ignore¶

• In very rare cases, merging two identical code fragments can make the code less intuitive
• In test code, sometimes it is acceptable to keep tests independent and duplicated for clarity

Module E: Dispensable #3 -- Lazy Class¶

What Is It?¶

A class that does too little to justify its existence. Understanding and maintaining classes always costs time and money. So if a class does not do enough to earn your attention, it should be deleted.

Signs and Symptoms¶

• The class has very few methods or fields
• The class does nothing more than wrap a single value
• Other classes do all the real work with this class's data

Reasons for the Problem¶

• A class may have become ridiculously small after refactoring reduced its original functionality
• Or it was designed to support future development that never happened
• Or it was created from an Extract Class refactoring that was too aggressive

Reference: RefactoringGuru -- Lazy Class

Module E: Dispensable #3 -- Lazy Class (Java Example -- Before)¶

// SMELL: Lazy Class -- does almost nothing
public class PhoneNumber {
    private String number;

    public String getNumber() {
        return number;
    }

    public void setNumber(String number) {
        this.number = number;
    }
    // That's it. No validation, no formatting, no logic at all.
}

public class Customer {
    private String name;
    private PhoneNumber phone; // Wrapper adds no value

    public String getPhoneNumber() {
        return phone.getNumber();
    }

    public void setPhoneNumber(String number) {
        phone.setNumber(number);
    }
}

Module E: Dispensable #3 -- Lazy Class (Java Example -- After)¶

// REFACTORED: Inline Class -- merge lazy class into its user
public class Customer {
    private String name;
    private String phone; // Simple field, no wrapper needed

    public String getPhone() { return phone; }
    public void setPhone(String phone) { this.phone = phone; }
}

// ALTERNATIVE: If PhoneNumber SHOULD exist, give it real behavior
public class PhoneNumber {
    private String areaCode;
    private String number;

    public PhoneNumber(String rawNumber) {
        validate(rawNumber);
        parse(rawNumber);
    }

    private void validate(String rawNumber) {
        if (!rawNumber.matches("\\d{3}-\\d{4}"))
            throw new IllegalArgumentException("Invalid phone number");
    }

    public String format() {
        return "(" + areaCode + ") " + number;
    }
    // Now PhoneNumber earns its keep!
}