CEN206 Object-Oriented Programming¶

Week-13 (Refactoring Techniques)¶

Spring Semester, 2025-2026¶

Download DOC-PDF, DOC-DOCX, SLIDE

Week-13 Overview¶

Refactoring Techniques (All 66 Techniques)¶

Source: https://refactoring.guru/refactoring/techniques

What is Refactoring?¶

• Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
• Each transformation (called a "refactoring") does little, but a sequence of transformations can produce a significant restructuring.
• The goal is to make code easier to understand, cheaper to modify, and safer to extend.

Why Refactor?¶

• Improves software design -- Without refactoring, the design of a program will decay over time.
• Makes software easier to understand -- Code that communicates its purpose clearly is easier to maintain.
• Helps find bugs -- Clarifying code structure makes bugs more visible.
• Helps you program faster -- Good design enables rapid development of new features.

When to Refactor?¶

• Rule of Three: The first time you do something, just do it. The second time, you wince at duplication but do it anyway. The third time, you refactor.
• When adding a feature: Refactor to make the new feature easier to add.
• When fixing a bug: Refactor to make the bug obvious.
• During code review: Refactor to improve readability and maintainability.

Refactoring Techniques - Overview Diagram¶

Module A: Composing Methods¶

9 Techniques for Better Method Structure¶

Module A Outline¶

Composing Methods¶

These refactorings deal with how methods are composed. Much of refactoring is about composing methods to properly package code. Almost all the time, the root problem is methods that are too long.

1. Extract Method
2. Inline Method
3. Extract Variable
4. Inline Temp
5. Replace Temp with Query
6. Split Temporary Variable
7. Remove Assignments to Parameters
8. Replace Method with Method Object
9. Substitute Algorithm

A1. Extract Method¶

What: Move a code fragment into a separate method with a descriptive name.

Problem: You have a code fragment that can be grouped together. Long methods are hard to understand and maintain.

Solution: Turn the fragment into a method whose name explains the purpose of the method.

When to use: Methods exceed 10-15 lines; code sections perform a distinct task; logic is duplicated.

When NOT to use: The extracted code is genuinely a one-time operation; the new method would have excessive parameters.

A1. Extract Method -- Before¶

public class Order {
    private String name;
    private List<LineItem> items;

    public void printOwing() {
        double outstanding = 0.0;

        // print banner
        System.out.println("**************************");
        System.out.println("***** Customer Owes ******");
        System.out.println("**************************");

        // calculate outstanding
        for (LineItem item : items) {
            outstanding += item.getAmount();
        }

        // print details
        System.out.println("name: " + name);
        System.out.println("amount: " + outstanding);
    }
}

A1. Extract Method -- After¶

public class Order {
    private String name;
    private List<LineItem> items;

    public void printOwing() {
        printBanner();
        double outstanding = calculateOutstanding();
        printDetails(outstanding);
    }

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

    private double calculateOutstanding() {
        double outstanding = 0.0;
        for (LineItem item : items) {
            outstanding += item.getAmount();
        }
        return outstanding;
    }

    private void printDetails(double outstanding) {
        System.out.println("name: " + name);
        System.out.println("amount: " + outstanding);
    }
}

Extract Method - Before/After Diagram¶

A2. Inline Method¶

What: Replace a method call with the method's body and delete the method.

Problem: When a method body is just as clear as the method name, or the method body is trivially simple, the indirection adds no value.

Solution: Put the method's body into the body of its callers and remove the method.

When to use: Method bodies are clearer than the method names; simple delegation methods have outlived their purpose.

When NOT to use: The method is overridden in subclasses (inlining would break polymorphism); the method is called from many places where simplicity matters.

A2. Inline Method -- Before / After¶

// Before
class PizzaDelivery {
    int getRating() {
        return moreThanFiveLateDeliveries() ? 2 : 1;
    }
    boolean moreThanFiveLateDeliveries() {
        return numberOfLateDeliveries > 5;
    }
}

// After
class PizzaDelivery {
    int getRating() {
        return numberOfLateDeliveries > 5 ? 2 : 1;
    }
}

By minimizing the number of unneeded methods, you make the code more straightforward.

A3. Extract Variable¶

What: Place the result of an expression (or its parts) in separate variables that are self-explanatory.

Problem: You have an expression that is hard to understand, particularly in conditional statements or multi-part arithmetic.

Solution: Assign expression results to self-explanatory variables.

When to use: Complex conditionals need clarification; long arithmetic expressions lack intermediate results.

When NOT to use: Simple, self-evident expressions; when the extracted variable appears only once.

A3. Extract Variable -- Before / After¶

// Before
public class Product {
    private int quantity;
    private double itemPrice;

    public double getPrice() {
        return quantity * itemPrice
            - Math.max(0, quantity - 500) * itemPrice * 0.05
            + Math.min(quantity * itemPrice * 0.1, 100.0);
    }
}

// After
public class Product {
    private int quantity;
    private double itemPrice;

    public double getPrice() {
        double basePrice = quantity * itemPrice;
        double quantityDiscount = Math.max(0, quantity - 500) * itemPrice * 0.05;
        double shipping = Math.min(basePrice * 0.1, 100.0);
        return basePrice - quantityDiscount + shipping;
    }
}

A4. Inline Temp¶

What: Replace all references to a temporary variable with the expression itself.

Problem: You have a temporary variable that is assigned to once with a simple expression, and the temp is getting in the way of other refactorings.

Solution: Replace all references to that temp with the expression.

When to use: The temp is blocking another refactoring (e.g., Replace Temp with Query); the variable adds no clarity.

When NOT to use: The expression is evaluated multiple times with side effects; removing the variable reduces readability.

// Before
double basePrice = order.basePrice();
return (basePrice > 1000);

// After
return (order.basePrice() > 1000);

A5. Replace Temp with Query¶

What: Extract the expression into a method and replace all references to the temp with the method call.

Problem: You are using a temporary variable to hold the result of an expression.

Solution: Move the expression to a separate method. Replace all references to the temp with the method call. The new method can then be used in other methods.

When to use: When a temp is used in a single method but the expression is useful in other methods too.

When NOT to use: When the expression has side effects or performance-critical calculations that should not be repeated.

A5. Replace Temp with Query -- Before / After¶

// Before
public class Product {
    private int quantity;
    private double itemPrice;

    double getPrice() {
        double basePrice = quantity * itemPrice;
        if (basePrice > 1000) {
            return basePrice * 0.95;
        }
        return basePrice * 0.98;
    }
}

// After
public class Product {
    private int quantity;
    private double itemPrice;

    double getPrice() {
        if (basePrice() > 1000) {
            return basePrice() * 0.95;
        }
        return basePrice() * 0.98;
    }

    private double basePrice() {
        return quantity * itemPrice;
    }
}

A6. Split Temporary Variable¶

What: Use a separate temporary variable for each assignment.

Problem: You have a local variable that is assigned more than once, but it is not a loop variable or a collecting variable.

Solution: Make a separate temporary variable for each assignment. Each temp should be assigned only once.

When to use: When a temp is used for two different things, it confuses the reader. Use a separate variable for each purpose.

When NOT to use: Loop counters or accumulator variables that are naturally reassigned.

A6. Split Temporary Variable -- Before / After¶

// Before
public class Rectangle {
    double height;
    double width;

    void calculate() {
        double temp = 2 * (height + width);
        System.out.println("Perimeter: " + temp);
        temp = height * width;
        System.out.println("Area: " + temp);
    }
}

// After
public class Rectangle {
    double height;
    double width;

    void calculate() {
        double perimeter = 2 * (height + width);
        System.out.println("Perimeter: " + perimeter);
        double area = height * width;
        System.out.println("Area: " + area);
    }
}

A7. Remove Assignments to Parameters¶

What: Use a local variable instead of assigning to a parameter.

Problem: A value is assigned to a parameter inside the method's body.

Solution: Use a local variable instead of the parameter.

When to use: When a method modifies a parameter value, blurring the line between input values and local working variables.

When NOT to use: In languages with pass-by-reference where modifying the parameter is the intended behavior.

// Before
int discount(int inputVal, int quantity) {
    if (quantity > 50) inputVal -= 2;
    return inputVal;
}

// After
int discount(int inputVal, int quantity) {
    int result = inputVal;
    if (quantity > 50) result -= 2;
    return result;
}

A8. Replace Method with Method Object¶

What: Transform a long method into a separate class so that local variables become fields.

Problem: You have a long method in which local variables are so intertwined that you cannot apply Extract Method.

Solution: Transform the method into a separate class so that the local variables become fields of the class. Then you can split the method into several methods within the same class.

When to use: When Extract Method is blocked by complex local variable dependencies.

When NOT to use: When the method can be simplified by other, simpler refactorings first.

A8. Replace Method with Method Object -- Before¶

public class Order {
    public double price() {
        double primaryBasePrice;
        double secondaryBasePrice;
        double tertiaryBasePrice;
        // long computation using all three variables...
        primaryBasePrice = quantity * itemPrice;
        secondaryBasePrice = primaryBasePrice * 0.9;
        tertiaryBasePrice = primaryBasePrice * 0.8;
        return primaryBasePrice + secondaryBasePrice + tertiaryBasePrice;
    }
}

A8. Replace Method with Method Object -- After¶

public class PriceCalculator {
    private double primaryBasePrice;
    private double secondaryBasePrice;
    private double tertiaryBasePrice;
    private Order order;

    public PriceCalculator(Order order) {
        this.order = order;
    }

    public double compute() {
        primaryBasePrice = order.getQuantity() * order.getItemPrice();
        secondaryBasePrice = primaryBasePrice * 0.9;
        tertiaryBasePrice = primaryBasePrice * 0.8;
        return primaryBasePrice + secondaryBasePrice + tertiaryBasePrice;
    }
}

Replace Method with Method Object - Diagram¶

A9. Substitute Algorithm¶

What: Replace the body of a method with a new, clearer algorithm.

Problem: You want to replace an existing algorithm with one that is clearer or more efficient.

Solution: Replace the body of the method that implements the algorithm with a new algorithm.

When to use: When you find a simpler or more efficient way to accomplish what a method does; when the existing algorithm is overly complex.

When NOT to use: When the existing algorithm is already optimal and well-understood.

A9. Substitute Algorithm -- Before / After¶

// Before
String foundPerson(String[] people) {
    for (int i = 0; i < people.length; i++) {
        if (people[i].equals("Don")) { return "Don"; }
        if (people[i].equals("John")) { return "John"; }
        if (people[i].equals("Kent")) { return "Kent"; }
    }
    return "";
}

// After
String foundPerson(String[] people) {
    List<String> candidates = List.of("Don", "John", "Kent");
    for (String person : people) {
        if (candidates.contains(person)) {
            return person;
        }
    }
    return "";
}

Module A -- Takeaway¶

Composing Methods: Key Points¶

Module B: Moving Features Between Objects¶

8 Techniques for Proper Responsibility Distribution¶

Module B Outline¶

Moving Features Between Objects¶

These refactorings address how to distribute functionality among classes. The key decisions are where to put responsibilities. If a class has too many responsibilities, use Extract Class. If a class is underperforming, use Inline Class.

1. Move Method
2. Move Field
3. Extract Class
4. Inline Class
5. Hide Delegate
6. Remove Middle Man
7. Introduce Foreign Method
8. Introduce Local Extension

B1. Move Method¶

What: Create the method in the class that uses it most, and redirect or remove the original.

Problem: A method is used more in another class than in its own class.

Solution: Create a new method in the class that uses the method the most, then move the body of the old method there. Turn the old method into a simple delegation, or remove it entirely.

When to use: When a method accesses data from another object more than its own.

When NOT to use: When the method uses many features of its current class equally.

B1. Move Method -- Before / After¶

// Before
class Account {
    private AccountType type;
    private int daysOverdrawn;

    double overdraftCharge() {
        if (type.isPremium()) {
            double result = 10;
            if (daysOverdrawn > 7) {
                result += (daysOverdrawn - 7) * 0.85;
            }
            return result;
        }
        return daysOverdrawn * 1.75;
    }

    double bankCharge() {
        double result = 4.5;
        if (daysOverdrawn > 0) {
            result += overdraftCharge();
        }
        return result;
    }
}

// After -- overdraftCharge moved to AccountType
class AccountType {
    double overdraftCharge(int daysOverdrawn) {
        if (isPremium()) {
            double result = 10;
            if (daysOverdrawn > 7) {
                result += (daysOverdrawn - 7) * 0.85;
            }
            return result;
        }
        return daysOverdrawn * 1.75;
    }
}

Move Method - Before/After Diagram¶

B2. Move Field¶

What: Move a field to the class that uses it more often.

Problem: A field is used more in another class than in its own class.

Solution: Create a field in a new class and redirect all users of the old field to it.

When to use: When a field is used more by methods of another class; as part of Extract Class.

When NOT to use: When the field is central to the current class's identity.

// Before
class Account {
    private double interestRate;
    private AccountType type;
}

// After -- interestRate moved to AccountType
class AccountType {
    private double interestRate;
    double getInterestRate() { return interestRate; }
}
class Account {
    private AccountType type;
    double getInterestRate() { return type.getInterestRate(); }
}

B3. Extract Class¶

What: Create a new class containing fields and methods for a distinct responsibility.

Problem: When one class does the work of two, awkwardness results. The class has too many responsibilities.

Solution: Create a new class and move the relevant fields and methods from the old class into the new class.

When to use: When a class has features that are naturally grouped and could stand on their own.

When NOT to use: When the class is still cohesive and splitting it would create unnecessary coupling.

B3. Extract Class -- Before / After¶

// Before
class Person {
    private String name;
    private String officeAreaCode;
    private String officeNumber;

    String getTelephoneNumber() {
        return "(" + officeAreaCode + ") " + officeNumber;
    }
}

// After
class Person {
    private String name;
    private TelephoneNumber officeTelephone = new TelephoneNumber();

    String getTelephoneNumber() {
        return officeTelephone.getTelephoneNumber();
    }
}

class TelephoneNumber {
    private String areaCode;
    private String number;

    String getTelephoneNumber() {
        return "(" + areaCode + ") " + number;
    }
}

Extract Class - Before/After Diagram¶

B4. Inline Class¶

What: Move all features from an underperforming class into another class and delete it.

Problem: A class does almost nothing and is not responsible for anything, and no additional responsibilities are planned for it.

Solution: Move all features from the class to another one and delete the empty class.

When to use: After refactorings have stripped a class of all but a thin wrapper of functionality.

When NOT to use: When the class still has a clear responsibility or is expected to grow.

// Before
class Person {
    private TelephoneNumber officeTelephone;
    String getAreaCode() { return officeTelephone.getAreaCode(); }
}
class TelephoneNumber { /* only areaCode and number */ }

// After -- TelephoneNumber merged back into Person
class Person {
    private String officeAreaCode;
    private String officeNumber;
    String getAreaCode() { return officeAreaCode; }
}

B5. Hide Delegate¶

What: Create a delegate method on the server to hide the delegate from the client.

Problem: The client gets object B from object A, then calls a method of object B (law of Demeter violation: a.getB().doSomething()).

Solution: Create a method in class A that delegates the call to B, shielding the client from knowing about B.

When to use: When clients navigate through chains of objects (message chains).

When NOT to use: When the delegate is a widely-known, stable API.

// Before
class Person {
    Department department;
    Department getDepartment() { return department; }
}
// Client code: person.getDepartment().getManager();

// After
class Person {
    Department department;
    Person getManager() { return department.getManager(); }
}
// Client code: person.getManager();

B6. Remove Middle Man¶

What: Have the client call the delegate directly, removing forwarding methods.

Problem: A class has too many methods that simply delegate to another object. The server class becomes a "middle man".

Solution: Delete the middle man methods and let the client call the end object directly.

When to use: When a class is overwhelmed with simple delegating methods; when Hide Delegate was overdone.

When NOT to use: When hiding the delegate is important for encapsulation.

// Before
class Person {
    Department department;
    Person getManager() { return department.getManager(); }
    // many more delegations...
}
// Client: person.getManager();

// After
class Person {
    Department department;
    Department getDepartment() { return department; }
}
// Client: person.getDepartment().getManager();

B7. Introduce Foreign Method¶

What: Add a utility method to a client class, passing the server object as an argument.

Problem: A utility class that you use does not contain the method that you need, and you cannot add the method to the class.

Solution: Create the method in a client class and pass an instance of the utility class as its first argument.

When to use: When you need just one or two extra methods on a class you cannot modify.

When NOT to use: When you need many methods -- use Introduce Local Extension instead.

// Before
Date newStart = new Date(previousEnd.getYear(),
    previousEnd.getMonth(), previousEnd.getDate() + 1);

// After
Date newStart = nextDay(previousEnd);

private static Date nextDay(Date date) {
    return new Date(date.getYear(), date.getMonth(), date.getDate() + 1);
}

B8. Introduce Local Extension¶

What: Create a new class (subclass or wrapper) that contains the extra methods you need.

Problem: A utility class lacks several methods that you need, and you cannot add methods to the class.

Solution: Create a new class containing the extra methods. Make this extension class a subclass or a wrapper of the original.

When to use: When you need many extra methods on a class you cannot modify.

When NOT to use: When only one or two methods are needed (use Introduce Foreign Method instead).

B8. Introduce Local Extension -- Example¶

// Wrapper approach
class MfDateWrapper {
    private Date original;

    public MfDateWrapper(Date date) {
        this.original = date;
    }

    public MfDateWrapper(String dateString) {
        this.original = new Date(dateString);
    }

    public Date nextDay() {
        return new Date(original.getYear(), original.getMonth(), original.getDate() + 1);
    }

    public int dayOfYear() {
        // custom implementation
        Calendar cal = Calendar.getInstance();
        cal.setTime(original);
        return cal.get(Calendar.DAY_OF_YEAR);
    }

    // delegate all original methods...
    public int getYear() { return original.getYear(); }
    public int getMonth() { return original.getMonth(); }
    public int getDate() { return original.getDate(); }
}

Module B -- Takeaway¶

Moving Features Between Objects: Key Points¶

Module C: Organizing Data¶

15 Techniques for Better Data Management¶

Module C Outline¶

Organizing Data¶

These refactorings make data handling easier by replacing primitives with rich class representations and simplifying class associations.

1. Self Encapsulate Field
2. Replace Data Value with Object
3. Change Value to Reference
4. Change Reference to Value
5. Replace Array with Object
6. Duplicate Observed Data
7. Change Unidirectional Association to Bidirectional
8. Change Bidirectional Association to Unidirectional
9. Replace Magic Number with Symbolic Constant
10. Encapsulate Field
11. Encapsulate Collection
12. Replace Type Code with Class
13. Replace Type Code with Subclasses
14. Replace Type Code with State/Strategy
15. Replace Subclass with Fields

C1. Self Encapsulate Field¶

What: Access a field only through getter and setter methods, even within the class.

Problem: You directly access a private field inside the class, making it harder to change the field's behavior later.

Solution: Create a getter and setter for the field and use only those to access the field.

When to use: When you want to be able to override field access in subclasses; when you want to add validation or lazy initialization.

When NOT to use: When direct access is simpler and there is no foreseeable need for indirect access.

C1. Self Encapsulate Field -- Before / After¶

// Before
class IntRange {
    private int low, high;

    boolean includes(int arg) {
        return arg >= low && arg <= high;
    }
}

// After
class IntRange {
    private int low, high;

    int getLow() { return low; }
    int getHigh() { return high; }

    boolean includes(int arg) {
        return arg >= getLow() && arg <= getHigh();
    }
}

class CappedRange extends IntRange {
    private int cap;

    @Override
    int getHigh() {
        return Math.min(super.getHigh(), cap);
    }
}

C2. Replace Data Value with Object¶

What: Turn a data field into an object with its own fields and behavior.

Problem: You have a data field (e.g., a String for phone number) that needs additional data or behavior (e.g., formatting, validation).

Solution: Create a new class, place the old field and its behavior in the class, and store an object of this class in the original class.

When to use: When a simple field evolves to need its own behavior.

When NOT to use: When the data truly is just a simple value with no additional behavior needed.

C2. Replace Data Value with Object -- Before / After¶

// Before
class Order {
    private String customer; // just a name string

    String getCustomer() { return customer; }
    void setCustomer(String customer) { this.customer = customer; }
}

// After
class Order {
    private Customer customer;

    String getCustomerName() { return customer.getName(); }
    void setCustomer(String customerName) {
        this.customer = new Customer(customerName);
    }
}

class Customer {
    private String name;

    Customer(String name) { this.name = name; }
    String getName() { return name; }
}

C3. Change Value to Reference¶

What: Convert identical value objects into a single reference object.

Problem: You have many identical instances of a single class that you need to replace with a single object (e.g., multiple Customer objects for the same customer).

Solution: Convert the value objects into reference objects. Use a factory or registry to ensure only one instance exists for each logical entity.

When to use: When multiple equal objects should be the same physical object for consistency.

When NOT to use: When objects need to be independently mutable.

C3. Change Value to Reference -- Before / After¶

// Before -- each Order creates its own Customer
class Order {
    private Customer customer;

    Order(String customerName) {
        customer = new Customer(customerName);
    }
}

// After -- Orders share a single Customer reference
class Customer {
    private static Map<String, Customer> instances = new HashMap<>();

    static Customer getNamed(String name) {
        if (!instances.containsKey(name)) {
            instances.put(name, new Customer(name));
        }
        return instances.get(name);
    }

    private String name;
    private Customer(String name) { this.name = name; }
}

class Order {
    private Customer customer;

    Order(String customerName) {
        customer = Customer.getNamed(customerName);
    }
}

C4. Change Reference to Value¶

What: Make a reference object into a value object.

Problem: You have a reference object that is small, immutable, and awkward to manage (requires lifecycle management, registry, etc.).

Solution: Turn it into a value object. Make it immutable and override equals/hashCode.

When to use: When reference management overhead is not justified; when the object is small and rarely changes.

When NOT to use: When the object needs to be shared and mutated across the system.

// Before -- Currency as reference object with registry
Currency usd = Currency.get("USD");

// After -- Currency as value object
class Currency {
    private String code;
    Currency(String code) { this.code = code; }
    public boolean equals(Object o) {
        return o instanceof Currency && ((Currency)o).code.equals(code);
    }
    public int hashCode() { return code.hashCode(); }
}

C5. Replace Array with Object¶

What: Replace an array that contains different types of data with an object that has named fields.

Problem: You have an array whose elements mean different things (e.g., row[0] is name, row[1] is age).

Solution: Replace the array with an object that has a field for each element.

When to use: When array elements represent different concepts.

When NOT to use: When the array truly represents a list of same-type elements.

// Before
String[] row = new String[2];
row[0] = "Liverpool";
row[1] = "15";

// After
class Performance {
    private String name;
    private int wins;
    String getName() { return name; }
    int getWins() { return wins; }
}
Performance row = new Performance();
row.setName("Liverpool");
row.setWins(15);

C6. Duplicate Observed Data¶

What: Copy domain data into domain objects and set up an observer to synchronize the two.

Problem: Domain data is stored in GUI classes only, and domain methods need access to it.

Solution: Copy the data into a domain object and set up an observer to synchronize the two copies.

When to use: When GUI controls hold domain data that should be accessible to business logic.

When NOT to use: When data exists only for display purposes with no domain logic.

C6. Duplicate Observed Data -- Before / After¶

// Before -- domain data trapped in GUI
class IntervalWindow extends Frame {
    TextField startField;
    TextField endField;
    TextField lengthField;

    void calculateLength() {
        int start = Integer.parseInt(startField.getText());
        int end = Integer.parseInt(endField.getText());
        lengthField.setText(String.valueOf(end - start));
    }
}

// After -- domain object with observer
class Interval implements Observable {
    private int start, end;

    int getLength() { return end - start; }

    void setStart(int start) {
        this.start = start;
        notifyObservers();
    }
    void setEnd(int end) {
        this.end = end;
        notifyObservers();
    }
}

class IntervalWindow extends Frame implements Observer {
    Interval interval = new Interval();
    // GUI syncs with domain model via Observer pattern
}

C7. Change Unidirectional Association to Bidirectional¶

What: Add a back-pointer so both classes can refer to each other.

Problem: You have two classes that each need to use the features of the other, but there is only a one-way association.

Solution: Add a back reference and update both directions when the link changes.

When to use: When both objects need to navigate to each other.

When NOT to use: When a bidirectional link adds unnecessary complexity; prefer unidirectional links when possible.

C7. Change Unidirectional to Bidirectional -- Example¶

// Before -- Order knows Customer, but Customer doesn't know Orders
class Order {
    private Customer customer;
    Customer getCustomer() { return customer; }
    void setCustomer(Customer customer) { this.customer = customer; }
}

// After -- bidirectional association
class Order {
    private Customer customer;
    Customer getCustomer() { return customer; }
    void setCustomer(Customer customer) {
        if (this.customer != null) this.customer.removeOrder(this);
        this.customer = customer;
        if (customer != null) customer.addOrder(this);
    }
}

class Customer {
    private Set<Order> orders = new HashSet<>();
    Set<Order> getOrders() { return Collections.unmodifiableSet(orders); }
    void addOrder(Order order) { orders.add(order); }
    void removeOrder(Order order) { orders.remove(order); }
}

C8. Change Bidirectional Association to Unidirectional¶

What: Remove the unnecessary direction of a bidirectional association.

Problem: You have a bidirectional association but one class no longer needs features from the other.

Solution: Remove the unneeded end of the association.

When to use: When one class no longer uses the reference to the other; to simplify dependency structure.

When NOT to use: When both directions are actively used.

// Before -- bidirectional
class Order {
    Customer customer;
}
class Customer {
    Set<Order> orders;
}

// After -- only Order -> Customer remains
class Order {
    Customer customer;
}
class Customer {
    // orders field removed -- if needed, query from Order repository
}

C9. Replace Magic Number with Symbolic Constant¶

What: Replace a literal number with a named constant.

Problem: Your code uses a number that has a certain meaning to it (e.g., 9.81 for gravitational acceleration).

Solution: Replace this number with a constant that has a human-readable name explaining the meaning.

When to use: When a number's meaning is not obvious from context.

When NOT to use: When the number is self-evident (e.g., 0, 1 in trivial contexts).

// Before
double potentialEnergy(double mass, double height) {
    return mass * 9.81 * height;
}

// After
static final double GRAVITATIONAL_CONSTANT = 9.81;

double potentialEnergy(double mass, double height) {
    return mass * GRAVITATIONAL_CONSTANT * height;
}

C10. Encapsulate Field¶

What: Make a public field private and provide access methods.

Problem: You have a public field that is directly accessed by external classes.

Solution: Make the field private and provide getter and setter methods.

When to use: Always -- public fields violate encapsulation.

When NOT to use: In simple data-transfer objects where encapsulation is not a concern (though even then, it is a good practice).

// Before
class Person {
    public String name;
}
// Client: person.name = "John";

// After
class Person {
    private String name;
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
}
// Client: person.setName("John");

C11. Encapsulate Collection¶

What: Make a collection getter return a read-only view and provide separate add/remove methods.

Problem: A method returns a collection directly, allowing callers to modify it without the owning class knowing.

Solution: Make the getter return a read-only view or copy of the collection, and provide separate add/remove methods.

When to use: When external code can modify a collection without the owning class's knowledge.

When NOT to use: When the collection truly needs to be freely modified by external code (rare).

C11. Encapsulate Collection -- Before / After¶

// Before
class Course {}
class Person {
    private List<Course> courses = new ArrayList<>();
    List<Course> getCourses() { return courses; }
    void setCourses(List<Course> courses) { this.courses = courses; }
}
// Client: person.getCourses().add(new Course());  // bypasses Person

// After
class Person {
    private List<Course> courses = new ArrayList<>();

    List<Course> getCourses() {
        return Collections.unmodifiableList(courses);
    }

    void addCourse(Course course) {
        courses.add(course);
    }

    void removeCourse(Course course) {
        courses.remove(course);
    }
}
// Client: person.addCourse(new Course());  // Person controls its collection

Encapsulate Collection - Before/After Diagram¶

C12. Replace Type Code with Class¶

What: Replace a type code (int or String) with a class.

Problem: A class has a field containing a type code. The values of this type are not used in operator conditions and do not affect the behavior of the program.

Solution: Create a new class and use its objects instead of the type code values.

When to use: When type codes are used for data only (no behavior depends on them).

When NOT to use: When the type code affects behavior -- use Replace Type Code with Subclasses or State/Strategy instead.

C12. Replace Type Code with Class -- Before / After¶

// Before
class Person {
    static final int O = 0;
    static final int A = 1;
    static final int B = 2;
    static final int AB = 3;
    private int bloodGroup;
    Person(int bloodGroup) { this.bloodGroup = bloodGroup; }
}

// After
class BloodGroup {
    public static final BloodGroup O = new BloodGroup(0);
    public static final BloodGroup A = new BloodGroup(1);
    public static final BloodGroup B = new BloodGroup(2);
    public static final BloodGroup AB = new BloodGroup(3);

    private final int code;
    private BloodGroup(int code) { this.code = code; }
    int getCode() { return code; }
}

class Person {
    private BloodGroup bloodGroup;
    Person(BloodGroup bloodGroup) { this.bloodGroup = bloodGroup; }
}
// Usage: new Person(BloodGroup.A);

C13. Replace Type Code with Subclasses¶

What: Create subclasses for each value of the type code.

Problem: You have a coded type that directly affects program behavior (e.g., conditionals that switch on the type code).

Solution: Create subclasses for each value of the coded type. Extract the relevant behaviors from the original class to these subclasses. Replace control flow code with polymorphism.

When to use: When the type code affects behavior and the type does not change after creation.

When NOT to use: When the type code can change at runtime (use State/Strategy instead).

C13. Replace Type Code with Subclasses -- Before / After¶

// Before
class Employee {
    static final int ENGINEER = 0;
    static final int SALESMAN = 1;
    static final int MANAGER = 2;
    private int type;

    int payAmount() {
        switch (type) {
            case ENGINEER: return monthlySalary;
            case SALESMAN: return monthlySalary + commission;
            case MANAGER:  return monthlySalary + bonus;
            default: throw new RuntimeException("Invalid type");
        }
    }
}

// After
abstract class Employee {
    abstract int payAmount();
}
class Engineer extends Employee {
    int payAmount() { return monthlySalary; }
}
class Salesman extends Employee {
    int payAmount() { return monthlySalary + commission; }
}
class Manager extends Employee {
    int payAmount() { return monthlySalary + bonus; }
}

Replace Type Code with Subclasses - Diagram¶

C14. Replace Type Code with State/Strategy¶

What: Replace the type code with a state object using the State or Strategy pattern.

Problem: You have a coded type that affects behavior, but you cannot use subclassing because the type changes at runtime, or the class is already subclassed for another reason.

Solution: Replace the type code with a state object. Use the State or Strategy pattern.

When to use: When the type code affects behavior AND the type changes during the object's lifetime.

When NOT to use: When the type is immutable after construction (use Subclasses instead).

C14. Replace Type Code with State/Strategy -- Example¶

// After applying State/Strategy pattern
abstract class EmployeeType {
    abstract int payAmount(Employee employee);
}

class Engineer extends EmployeeType {
    int payAmount(Employee emp) { return emp.getMonthlySalary(); }
}
class Salesman extends EmployeeType {
    int payAmount(Employee emp) { return emp.getMonthlySalary() + emp.getCommission(); }
}
class Manager extends EmployeeType {
    int payAmount(Employee emp) { return emp.getMonthlySalary() + emp.getBonus(); }
}

class Employee {
    private EmployeeType type;

    void setType(EmployeeType type) { this.type = type; }

    int payAmount() { return type.payAmount(this); }
}
// Now the type can change at runtime: emp.setType(new Manager());

Replace Type Code with State/Strategy - Diagram¶

C15. Replace Subclass with Fields¶

What: Replace subclasses whose only difference is constant-returning methods with fields in the parent class.

Problem: You have subclasses that differ only in their methods that return constant data (e.g., getCode() returns different values).

Solution: Replace the methods with fields in the parent class and eliminate the subclasses.

When to use: When subclasses add no real behavior, only returning different constant values.

When NOT to use: When subclasses have meaningful behavioral differences beyond returning constants.

C15. Replace Subclass with Fields -- Before / After¶

// Before
abstract class Person {
    abstract boolean isMale();
    abstract char getCode();
}
class Male extends Person {
    boolean isMale() { return true; }
    char getCode() { return 'M'; }
}
class Female extends Person {
    boolean isMale() { return false; }
    char getCode() { return 'F'; }
}

// After
class Person {
    private final boolean male;
    private final char code;

    private Person(boolean male, char code) {
        this.male = male;
        this.code = code;
    }

    static Person createMale() { return new Person(true, 'M'); }
    static Person createFemale() { return new Person(false, 'F'); }

    boolean isMale() { return male; }
    char getCode() { return code; }
}

Module C -- Takeaway¶

Organizing Data: Key Points¶

Module D: Simplifying Conditional Expressions¶

8 Techniques for Cleaner Conditionals¶

Module D Outline¶

Simplifying Conditional Expressions¶

Conditionals tend to get more and more complicated in their logic over time, and there are yet more techniques to combat this. These refactorings reduce complexity and improve readability of conditional logic.

1. Decompose Conditional
2. Consolidate Conditional Expression
3. Consolidate Duplicate Conditional Fragments
4. Remove Control Flag
5. Replace Nested Conditional with Guard Clauses
6. Replace Conditional with Polymorphism
7. Introduce Null Object
8. Introduce Assertion

D1. Decompose Conditional¶

What: Extract complex conditional parts into separate, well-named methods.

Problem: You have a complex conditional (if-then-else or switch) whose condition, then-branch, and else-branch are hard to understand.

Solution: Decompose the complicated parts of the conditional into separate methods: the condition, the then-branch, and the else-branch.

When to use: When conditional logic becomes difficult to understand at a glance.

When NOT to use: When the condition is already simple and self-documenting.

D1. Decompose Conditional -- Before / After¶

// Before
double calculateCharge(Date date, int quantity) {
    double charge;
    if (date.before(SUMMER_START) || date.after(SUMMER_END)) {
        charge = quantity * winterRate + winterServiceCharge;
    } else {
        charge = quantity * summerRate;
    }
    return charge;
}

// After
double calculateCharge(Date date, int quantity) {
    if (isNotSummer(date)) {
        return winterCharge(quantity);
    }
    return summerCharge(quantity);
}

boolean isNotSummer(Date date) {
    return date.before(SUMMER_START) || date.after(SUMMER_END);
}

double winterCharge(int quantity) {
    return quantity * winterRate + winterServiceCharge;
}

double summerCharge(int quantity) {
    return quantity * summerRate;
}

Decompose Conditional - Before/After Diagram¶

D2. Consolidate Conditional Expression¶

What: Combine multiple conditionals that lead to the same result into a single expression.

Problem: You have multiple conditionals that lead to the same result or action.

Solution: Consolidate all these conditionals into a single expression, then extract the combined condition into a well-named method.

When to use: When multiple conditions lead to the same result and can be logically combined.

When NOT to use: When the conditions are truly independent checks that only coincidentally return the same result.

D2. Consolidate Conditional Expression -- Before / After¶

// Before
double disabilityAmount() {
    if (seniority < 2) return 0;
    if (monthsDisabled > 12) return 0;
    if (isPartTime) return 0;
    // compute the disability amount
    return basePay * 0.5;
}

// After
double disabilityAmount() {
    if (isNotEligibleForDisability()) return 0;
    return basePay * 0.5;
}

boolean isNotEligibleForDisability() {
    return seniority < 2 || monthsDisabled > 12 || isPartTime;
}

D3. Consolidate Duplicate Conditional Fragments¶

What: Move identical code that appears in all branches outside the conditional.

Problem: Identical code can be found in all branches of a conditional.

Solution: Move the duplicated code outside of the conditional.

When to use: When the same statement appears at the beginning or end of every branch.

When NOT to use: When the code only looks similar but is semantically different in each branch.

// Before
if (isSpecialDeal()) {
    total = price * 0.95;
    send();
} else {
    total = price * 0.98;
    send();
}

// After
if (isSpecialDeal()) {
    total = price * 0.95;
} else {
    total = price * 0.98;
}
send();

D4. Remove Control Flag¶

What: Use break, continue, or return instead of a boolean control flag.

Problem: You have a boolean variable that acts as a control flag for multiple boolean expressions.

Solution: Use break, continue, and return instead of the flag variable.

When to use: When boolean variables are used solely to control loop or conditional execution flow.

When NOT to use: When the flag variable has genuine domain meaning beyond flow control.

D4. Remove Control Flag -- Before / After¶

// Before
boolean found = false;
for (Person person : people) {
    if (!found) {
        if (person.getName().equals("Don")) {
            sendAlert();
            found = true;
        }
        if (person.getName().equals("John")) {
            sendAlert();
            found = true;
        }
    }
}

// After
for (Person person : people) {
    if (person.getName().equals("Don") || person.getName().equals("John")) {
        sendAlert();
        break;
    }
}

D5. Replace Nested Conditional with Guard Clauses¶

What: Use guard clauses for special cases, leaving the normal path un-indented.

Problem: You have a group of nested conditionals that makes it hard to determine the normal flow of code execution.

Solution: Isolate all special checks and edge cases into separate clauses (guard clauses) and place them before the main logic. Return early from each guard clause.

When to use: When deeply nested conditions make code hard to follow.

When NOT to use: When the condition truly represents two equal alternatives (use if-else).

D5. Replace Nested Conditional with Guard Clauses -- Before / After¶

// Before
double getPayAmount() {
    double result;
    if (isDead) {
        result = deadAmount();
    } else {
        if (isSeparated) {
            result = separatedAmount();
        } else {
            if (isRetired) {
                result = retiredAmount();
            } else {
                result = normalPayAmount();
            }
        }
    }
    return result;
}

// After
double getPayAmount() {
    if (isDead) return deadAmount();
    if (isSeparated) return separatedAmount();
    if (isRetired) return retiredAmount();
    return normalPayAmount();
}

D6. Replace Conditional with Polymorphism¶

What: Create subclasses matching conditional branches and use polymorphic method calls.

Problem: You have a conditional that performs various actions depending on object type or properties.

Solution: Create subclasses matching each condition branch. Create a shared method via polymorphism and move the relevant code from each branch to the matching subclass. The original method becomes abstract.

When to use: When conditionals depend on object types; when the same conditional structure repeats.

When NOT to use: When the conditional is simple and unlikely to grow; when creating subclasses is overkill.

D6. Replace Conditional with Polymorphism -- Before / After¶

// Before
class Bird {
    String type;
    double getSpeed() {
        switch (type) {
            case "EUROPEAN":  return getBaseSpeed();
            case "AFRICAN":   return getBaseSpeed() - getLoadFactor() * numberOfCoconuts;
            case "NORWEGIAN_BLUE": return (isNailed) ? 0 : getBaseSpeed();
            default: throw new RuntimeException("Unknown type");
        }
    }
}

// After
abstract class Bird {
    abstract double getSpeed();
}
class European extends Bird {
    double getSpeed() { return getBaseSpeed(); }
}
class African extends Bird {
    double getSpeed() { return getBaseSpeed() - getLoadFactor() * numberOfCoconuts; }
}
class NorwegianBlue extends Bird {
    double getSpeed() { return (isNailed) ? 0 : getBaseSpeed(); }
}

Replace Conditional with Polymorphism - Diagram¶

D7. Introduce Null Object¶

What: Instead of returning null, return a special null object that provides default behavior.

Problem: Since some methods return null instead of real objects, you have many checks for null in your code.

Solution: Instead of null, return a null object that exhibits default behavior.

When to use: When null checks clutter code; when null represents "nothing" with a known default behavior.

When NOT to use: When null has genuine meaning (e.g., "not found" must be handled differently from "found with defaults").

D7. Introduce Null Object -- Before / After¶

// Before
class Site {
    Customer getCustomer() {
        return customer; // may return null
    }
}
// Client:
Customer c = site.getCustomer();
String name = (c == null) ? "occupant" : c.getName();
String plan = (c == null) ? BillingPlan.basic() : c.getPlan();

// After
class NullCustomer extends Customer {
    @Override String getName() { return "occupant"; }
    @Override String getPlan() { return BillingPlan.basic(); }
    @Override boolean isNull() { return true; }
}

class Site {
    Customer getCustomer() {
        return (customer == null) ? new NullCustomer() : customer;
    }
}
// Client: no null checks needed
String name = site.getCustomer().getName();
String plan = site.getCustomer().getPlan();

Introduce Null Object - Diagram¶

D8. Introduce Assertion¶

What: Replace assumptions about program state with explicit assertion checks.

Problem: A section of code assumes something about the current state of the object or parameter values but does not enforce it.

Solution: Replace these assumptions with specific assertion checks.

When to use: When you need to document and enforce required preconditions; to make implicit assumptions explicit.

When NOT to use: Do not use assertions for input validation in public APIs (use exceptions instead). Assertions are for programmer errors, not user errors.

D8. Introduce Assertion -- Before / After¶

// Before
double getExpenseLimit() {
    // should have either expense limit or a primary project
    return (expenseLimit != NULL_EXPENSE)
        ? expenseLimit
        : primaryProject.getMemberExpenseLimit();
}

// After
double getExpenseLimit() {
    assert (expenseLimit != NULL_EXPENSE || primaryProject != null)
        : "Must have either expense limit or primary project";

    return (expenseLimit != NULL_EXPENSE)
        ? expenseLimit
        : primaryProject.getMemberExpenseLimit();
}

Assertions make implicit assumptions explicit and help catch programmer errors early.

Module D -- Takeaway¶

Simplifying Conditional Expressions: Key Points¶

Module E: Simplifying Method Calls¶

14 Techniques for Cleaner Interfaces¶