Refactoring and code smells

BCS1430

Dr. Ashish Sai

📅 Week 3 Lecture 1

💻 BCS1430.ashish.nl

📍 EPD150 MSM Conference Hall

Introduction to Refactoring

Introduction to Refactoring

• Refactoring: The process of improving the internal structure of code without changing its external behavior.

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of these transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

Motivations for Refactoring

• Enhance Code Clarity
• Mitigate Technical Debt ¹
• Ease Future Modifications
• Spot and Resolve Defects

Refactoring improves the design of software, makes software easier to understand, helps find bugs, and helps you program faster. Refactoring your code regularly helps to maintain a high code quality and reduce technical debt. It ensures the software is easier to understand and modify, making future changes quicker and less costly.

• Enhance Code Clarity: Simplify the structure to increase readability and maintainability.
• Mitigate Technical Debt[1]: Address the build-up of earlier compromises to avoid compounding problems.
• Ease Future Modifications: Streamline code to accommodate changes and new functionalities more readily.
• Spot and Resolve Defects: Improve code transparency to more effectively identify and rectify errors.

1. Technical Debt: The implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

Refactoring Challenges

• Legacy Code: Navigating complex, undocumented systems.
• Time Management: Juggling refactoring and new features.
• Bug Risk: Ensuring thorough testing.
• Stakeholder Buy-In: Advocating the benefits of refactoring.

While refactoring can significantly improve the design of software, it also comes with its own set of challenges. Understanding complex and poorly documented legacy code can be difficult and time-consuming. There is always a risk of introducing bugs during the refactoring process, making comprehensive testing crucial. Additionally, there may be resistance from project stakeholders who prioritize new features over code quality improvements.

When to Refactor

• Before Adding a New Feature: Tidy code before adding new features.
• When Fixing a Bug: Simplify surrounding code for clarity and easier bug resolution.
• During Code Review: Implement identified enhancements.
• As You Go: Continually refine code during development.

The best time to refactor is just before you add a feature, fix a bug, or do a code review. Refactoring at these times has several advantages: If you refactor just before you add a feature, you usually get a cleaner design and find it easier to add the feature. If you refactor just before you fix a bug, you usually find the bug faster and make fewer errors fixing it. If you refactor as part of a code review, you consolidate your learning about the code and remove any debris that you find. Refactoring is also something that can and should be done continuously as you’re working on a project.

Refactoring Example

Refactoring

• Small, Behavior-Preserving Transformations: Minor yet cumulative modifications for major restructuring.

• Systematic Process: Ensures the external behavior remains consistent while improving internal architecture.

The Starting Code

Consider a video store’s calculation logic:

public double calculateTotalAmount(Customer customer) {
    double totalAmount = 0;
    for (Rental rental : customer.getRentals()) {
        double amount = 0;
        // ... switch statement ...
        totalAmount += amount;
    }
    return totalAmount;
}

Identifying the First Refactor - Extract Method

Goal: Simplify the calculateTotalAmount method by creating smaller, more readable chunks of code.

Extract the switch statement into amountFor in the Rental class:

public double amountFor(Rental rental) {
    double amount = 0;
    // ... case statements ...
    return amount;
}

Refactoring Step by Step

1. Identify a section to extract: Target a self-contained code chunk.
2. Create a new method: Move the code into a new method in the appropriate class.
3. Replace old code: Substitute the original code with the new method call.
4. Test: Ensure behavior remains consistent.

Benefits of Extract Method

• Improved Readability: The main method becomes concise.
• Reusability: Other system parts can now use the new method.
• Separation of Concerns: Enhances encapsulation.

Continuing the Refactoring

Look for opportunities to:

• Break down long methods.

• Move operations closer to data.

• Replace conditionals with polymorphism.

Polymorphism Over Conditionals

Before: Switch statements based on movie type.

After: Use polymorphism with subclasses like RegularMovie, NewReleaseMovie, and ChildrensMovie.

Implementing Polymorphism

1. Define a common interface: All movie types should respond to getCharge.
2. Create subclasses: Each represents a different movie type.
3. Move the logic: Shift charge calculation to the respective subclass.

Example:

public abstract class Movie {
    // ... existing code ...
    abstract double getCharge(int daysRented);
}

public class RegularMovie extends Movie {
    @Override
    double getCharge(int daysRented) {
        // Calculation for regular movies
    }
}

Benefits of Polymorphism

• Flexibility: Adding a new movie type is straightforward.

• Adherence to Open/Closed Principle: System is open for extension but closed for modification.

So far

• Encapsulation Achieved: Broke down a complex method into smaller, manageable parts, enhancing readability and flexibility.

• Refactoring Impact: Small, progressive enhancements yielding substantial overall improvements.

Principles of Refactoring

• Core Principles:

  • Do not change the observable behavior of the code.

  • Make small, incremental changes.

  • Test after each change.

  • Focus on simplicity and clarity.

Refactoring is all about making small, incremental changes to your code to improve its internal structure without changing its external behavior. These principles are the foundation that guides each step in the refactoring process, ensuring that the code’s functionality remains intact while its design and readability are enhanced.

Introduction to Code Smells

Introduction to Code Smells

• Code Smells: Indicators of potential issues in your code that may require refactoring.

• Importance: Recognizing smells is the first step towards improving code quality.

Introduction to Code Smells

• Common Smells: Include Duplicated Code, Long Method, Large Class, and more.

• Use smells as a guide, not a strict rule, to identify areas for improvement.

Code smells are certain structures in the code that indicate a violation of fundamental design principles and negatively impact design quality. They are not bugs; they do not prevent the program from functioning, but they increase the risk of bugs or failures in the future. Identifying and understanding these smells is crucial for maintaining a healthy and easily adaptable codebase.

1. Duplicated Code

• What It Is: The same code structure appearing in more than one place.

• Problems: Increases the likelihood of errors and makes the code harder to maintain.

Example

// Example of Duplicated Code
public void processOrder() {
    // ... some code ...
    double orderTotal = price * quantity;
    double tax = orderTotal * 0.05;
    double finalPrice = orderTotal + tax;
    // ... more code ...
}

public void calculateBill() {
    // ... some code ...
    double billTotal = itemPrice * itemCount;
    double tax = billTotal * 0.05;
    double finalAmount = billTotal + tax;
    // ... more code ...
}

1. Refactoring Duplicated Code

// Extracted method to handle tax and final price calculation
public double calculateTotalWithTax(double total) {
    double tax = total * 0.05;
    return total + tax;
}

public void processOrder() {
    // ... some code ...
    double orderTotal = price * quantity;
    double finalPrice = calculateTotalWithTax(orderTotal);
    // ... more code ...
}

public void calculateBill() {
    // ... some code ...
    double billTotal = itemPrice * itemCount;
    double finalAmount = calculateTotalWithTax(billTotal);
    // ... more code ...
}

By extracting the common logic into a method, we reduce duplication and improve maintainability.

Duplicated code is one of the most common smells and can occur for various reasons, such as copying and pasting code or parallel development. It’s problematic because any change needs to be made in multiple places, increasing the likelihood of mistakes. Refactoring aims to eliminate duplication and create a single source of truth.

2. Long Method - Problem

• What It Is: Methods with too many lines of code.

• Problems: Hard to understand and maintain. Often contain hidden bugs.

2. Long Method - Problem

    public class ReportGenerator {
        public void generateReport(DataSet data) {
            // Initialization and setup
            String report = "";
            // Complex data processing
            for (DataPoint point : data) {
                // Detailed data analysis and report generation
                report += analyzeDataPoint(point);
            }
            // More processing and formatting
            // Final report compilation
            System.out.println(report);
        }
    }

2. Long Method - Solution

• Break down into smaller methods, each with a clear purpose.

    public class ReportGenerator {
        public void generateReport(DataSet data) {
            String report = processDataForReport(data);
            outputReport(report);
        }

        private String processDataForReport(DataSet data) {
            String report = "";
            for (DataPoint point : data) {
                report += analyzeDataPoint(point);
            }
            return report;
        }

        private void outputReport(String report) {
            // Final report compilation and output
            System.out.println(report);
        }

        private String analyzeDataPoint(DataPoint point) {
            // Detailed data analysis
            // Return analysis result as String
        }
    }

• The generateReport method is now concise, with clear sub-methods handling specific parts of the report generation process.

Long methods are difficult to read, understand, and maintain. They often do too much and have hidden complexities. Refactoring such methods involves breaking them down into smaller, more manageable pieces that are easier to understand and test individually.

3. Large Class: Problem

• What It Is: Classes with too many responsibilities.

• Problems: Difficult to understand, maintain, and modify.

3. Large Class: Problem

    public class Employee {
        private String name;
        private String address;
        private String phoneNumber;
        private double salary;
        // ... many more attributes

        public void calculatePay() {
            // Method to calculate pay
        }

        public void save() {
            // Method to save employee details
        }

        // ... many more methods
    }

• This Employee class is handling personal details, pay calculations, and data storage, among other things.

3. Large Class: Solution

• Solution: Use techniques like Extract Class to divide into smaller, more focused classes.

    public class Employee {
        private String name;
        private EmployeeDetails details;
        private PayCalculator payCalculator;

        // Employee class now delegates responsibilities
    }

    public class EmployeeDetails {
        private String address;
        private String phoneNumber;
        // ... other personal details
    }

    public class PayCalculator {
        private double salary;

        public void calculatePay() {
            // Method to calculate pay
        }
    }

Large classes often become “god objects” that handle too many aspects of the application. They are challenging to understand and maintain. By refactoring, you can create a more modular design where each class has a clear, focused responsibility.

• Now, Employee delegates responsibilities to EmployeeDetails for personal information and PayCalculator for salary computations. This makes the classes easier to understand, maintain, and modify.

4. Long Parameter List

• What It Is: Methods with a high number of parameters.
• Problems: Hard to understand and use. Increases the risk of errors.

4. Long Parameter List

public void createProfile(String firstName, String lastName, String address, 
                          String city, String state, String zip, String phoneNumber) {
    // Method logic...
}

4. Solution to Long Parameter List

• Solution: Use objects to group parameters or replace parameters with method calls.

public class UserProfile {
    private String firstName;
    private String lastName;
    // Other fields...

    // Constructor
    public UserProfile(String firstName, String lastName, /* other parameters */) {
        this.firstName = firstName;
        this.lastName = lastName;
        // Initialize other fields...
    }

    // Getters and Setters...
}

// Now the method looks like this:
public void createProfile(UserProfile profile) {
    // Method logic using profile object...
}

4. Long Parameter List: Alternative Solution

• Alternative: Replace parameters with method calls to retrieve the needed information.

Example: Method Calls Instead of Parameters

// Assuming there's a class that holds user details already
UserProfile profile = getUserProfile(userId);

// Now the method can be called with fewer parameters
public void updateProfile(UserProfile profile) {
    String address = profile.getAddress();
    // Update logic...
}

Methods with long parameter lists are often confusing and error-prone. They make the code hard to understand and change. Refactoring can simplify these methods by reducing the number of parameters, making the method’s purpose clearer and its use easier.

5. Switch Statements

• What It Is: Excessive use of switch or complex if-else chains.
• Problems: Hard to modify and extend. Often violates Open/Closed Principle.

5. Switch Statements

public class AnimalSound {
    public String makeSound(String animalType) {
        switch (animalType) {
            case "dog":
                return "Bark";
            case "cat":
                return "Meow";
            case "cow":
                return "Moo";
            // More cases for different animals
            default:
                throw new IllegalArgumentException("Unknown animal type");
        }
    }
}

• Issues: Each new animal type requires modifying the makeSound method.

5. Switch Statements - Solution

• Solution: Use polymorphism and other design patterns to handle varying behavior more gracefully.

interface Animal {
    String makeSound();
}

class Dog implements Animal {
    public String makeSound() { return "Bark"; }
}

class Cat implements Animal {
    public String makeSound() { return "Meow"; }
}

class Cow implements Animal {
    public String makeSound() { return "Moo"; }
}

// Using the Animal interface
public class AnimalSound {
    public String makeSound(Animal animal) {
        return animal.makeSound();
    }
}

• Benefits: Easily extendable by adding new classes. No need to modify existing code to add new animal types, adhering to the Open/Closed Principle.

Switch statements and complex conditional logic are often signs of code that’s hard to modify and extend. They can usually be refactored using polymorphism or other design patterns to create a more flexible and maintainable structure.

Strategies for Detecting Smells

Strategies for Detecting Smells

• Regular Reviews: Peer reviews and pair programming can help identify smells.

• Refactoring Tools: Many IDEs and tools can point out common smells.

Detecting smells is as much an art as it is a science. Regular code reviews, tooling, and experience will help you identify potential issues in your code. The more you work with the code and understand its patterns, the easier it will become to spot and address smells.

Identifying Duplicated Code

• Identification: Look for similar code segments across different methods or classes.

• Examples:

  • Copy-pasted loops or conditionals.

  • Repeated code blocks in different parts of the application.

Issues: Makes maintenance harder, increases the risk of errors during updates, and bloats the codebase.

Extract Method

• Technique: Isolate repeated code into a single method.

Problem:

class ReportGenerator {
    void generateReport() {
        // ... some code ...
        System.out.println("Calculating...");
        int sum = 0;
        for(int i = 0; i < data.size(); i++) { sum += data.get(i); }
        System.out.println("Sum: " + sum);
        // ... more code ...
        // Repeated sum calculation in another method
    }
}

Extract Method

Refactored Code:

class ReportGenerator {
    private int calculateSum(List<Integer> data) {
        int sum = 0;
        for(Integer value : data) { sum += value; }
        return sum;
    }
    
    void generateReport() {
        // ... some code ...
        System.out.println("Sum: " + calculateSum(data));
        // ... more code ...
    }
}

• Benefits: Reduces redundancy, centralizes changes, and improves code readability.

Pull Up Method/Field

• Technique: Move duplicate code to a common superclass.

Problem:

class Dog {
    void eat() { System.out.println("Eating..."); }
}

class Cat {
    void eat() { System.out.println("Eating..."); }
}

Pull Up Method/Field

Refactored Code:

class Animal {
    void eat() { System.out.println("Eating..."); }
}

class Dog extends Animal {}

class Cat extends Animal {}

• Benefits: Eliminates duplicate code across subclasses, centralizes behavior for easier updates and maintenance.

Template Method (Design Pattern)

• Technique: Create a skeletal structure in a superclass with details filled in by subclasses.

Problem Code:

abstract class Game {
    void play() {
        start();
        // Duplicate game loop logic in each subclass
        end();
    }
}

class Chess extends Game {
    void start() { /*...*/ }
    void end() { /*...*/ }
    // Duplicate game loop logic
}

class Checkers extends Game {
    void start() { /*...*/ }
    void end() { /*...*/ }
    // Duplicate game loop logic
}

Template Method (Design Pattern)

abstract class Game {
    final void play() {
        start();
        runGame(); // Defined by subclasses
        end();
    }

    abstract void start();
    abstract void runGame();
    abstract void end();
}

class Chess extends Game {
    void start() { /*...*/ }
    void runGame() { /* Specific Chess logic */ }
    void end() { /*...*/ }
}

class Checkers extends Game {
    void start() { /*...*/ }
    void runGame() { /* Specific Checkers logic */ }
    void end() { /*...*/ }
}

• Benefits: Defines a fixed algorithm structure in the superclass with variable steps implemented in subclasses.

By addressing duplicated code, you reduce the risk of inconsistencies and errors. It’s not just about reducing the amount of code but ensuring a single point of truth for each piece of functionality.

Long Method

• Identification: Methods that span dozens of lines, often doing more than one thing.

• Example:

public void processOrder(Order order) {
    // Initialization code
    initializeOrderProcessing(order);
    // Validation code
    validateOrder(order);
    // Processing code
    processOrderItems(order);
    // Summary generation
    generateOrderSummary(order);
}

Refactoring Techniques: Long Method

• Extract Method: Break down into smaller methods with clear names indicating their purpose.

• Replace Temp with Query: Replace temporary variables with queries to the method itself.

• Introduce Parameter Object or Preserve Whole Object: Group parameters into objects.

Long Method: Extract Method

• Technique: Break down a long method into smaller methods with clear names indicating their purpose.

Problem Code:

public void printReport(List<Report> reports) {
    for(Report report : reports) {
        // Print header
        // Print details
        // Print footer
    }
}

Long Method: Extract Method

Refactored Code:

public void printReport(List<Report> reports) {
    for(Report report : reports) {
        printHeader(report);
        printDetails(report);
        printFooter(report);
    }
}

private void printHeader(Report report) { /*...*/ }
private void printDetails(Report report) { /*...*/ }
private void printFooter(Report report) { /*...*/ }

• Benefits: Each part of the code has a clear purpose, improving readability and maintainability.

Long Method: Replace Temp with Query

• Technique: Replace temporary variables with queries to the method itself.

Problem Code:

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

Long Method: Replace Temp with Query

Refactored Code:

public double calculateTotal() {
    if(basePrice() > 1000) {
        return basePrice() * 0.95;
    } else {
        return basePrice() * 0.98;
    }
}

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

• Benefits: Reduces the clutter of temporary variables and ensures that the calculation is always up to date.

Long Method: Parameter or Whole Object

• Technique: Group parameters into objects.

Problem Code:

public void createReservation(Date start, Date end, Guest guest, Room room) {
    // Logic using start, end, guest, and room
}

Long Method: Parameter or Whole Object

Refactored Code:

public class ReservationRequest {
    private Date start;
    private Date end;
    private Guest guest;
    private Room room;
    // Constructor and accessors
}

public void createReservation(ReservationRequest request) {
    // Logic using request object
}

• Benefits: Simplifies method signatures, makes the code more readable, and groups related data together.

Large Class

• Identification: Classes with an excessive number of fields, methods, or lines of code.

• Example:

    class Order {
        // Dozens of fields and methods handling various aspects of orders
    }

Large Class

• Refactoring Techniques:

  • Extract Class: Create new classes to handle parts of the functionality.

  • Extract Subclass or Extract Interface: Use when part of the behavior is used in only some instances.

Refactoring large classes typically involves breaking them down into smaller, more focused classes, each responsible for a specific part of the functionality. This leads to a codebase that’s easier to navigate and maintain.

Large Class: Extract Class

• Technique: Create new classes to handle parts of the functionality.

Problem Code:

class Order {
    private Customer customer;
    private List<Item> items;
    private Address shippingAddress;
    private Address billingAddress;
    // ... many more fields and methods related to payment, shipping, etc.

    void processOrder() { /* ... */ }
    void calculateTotal() { /* ... */ }
    // ... many more methods
}

Large Class: Extract Class

Refactored Code:

class Order {
    private Customer customer;
    private List<Item> items;
    private PaymentDetails paymentDetails;
    private ShippingDetails shippingDetails;
    // Simplified Order class
}

class PaymentDetails {
    private Address billingAddress;
    // ... payment related fields and methods
}

class ShippingDetails {
    private Address shippingAddress;
    // ... shipping related fields and methods
}

• Benefits: Reduces complexity by delegating responsibilities to new classes, improving readability and maintainability.

Large Class: Extract Subclass or Interface

• Technique: Use when part of the behavior is used in only some instances.

Problem Code:

class Order {
    private boolean isPriorityOrder;
    // ... many fields and methods

    void processOrder() {
        if (isPriorityOrder) {
            // Priority order processing
        } else {
            // Normal order processing
        }
    }
}

Large Class: Extract Subclass or Interface

Refactored Code (Extract Subclass):

class Order {
    // ... common fields and methods
}

class PriorityOrder extends Order {
    // Priority order specific fields and methods
    @Override
    void processOrder() {
        // Priority order processing
    }
}

class NormalOrder extends Order {
    // Normal order specific fields and methods
    @Override
    void processOrder() {
        // Normal order processing
    }
}

Large Class: Extract Subclass or Interface

Refactored Code (Extract Interface):

interface Order {
    void processOrder();
}

class PriorityOrder implements Order {
    // Priority order specific fields and methods
    public void processOrder() {
        // Priority order processing
    }
}

class NormalOrder implements Order {
    // Normal order specific fields and methods
    public void processOrder() {
        // Normal order processing
    }
}

• Benefits: Separates different behaviors into distinct classes or interfaces, enhancing the Single Responsibility Principle and making the system easier to understand and modify.

Long Parameter List

• Identification: Methods with a long list of parameters, making them hard to understand and use.

• Example:

  public void createReport(String title, String author, Date date, Data data, Format format, ...) {
      // Method body
  }

Long Parameter List

• Refactoring Techniques:

  • Introduce Parameter Object: Group related parameters into a single object.

  • Replace Method with Method Object: Turn the method into an object that has the original parameters as fields.

Refactoring methods with long parameter lists often involves creating more structured data types to represent the parameter sets, leading to clearer and more maintainable code.

Long Parameter List: Parameter Object

• Technique: Group related parameters into a single object.

Problem Code:

public void createReport(String title, String author, Date date, Data data, Format format) {
    // Method body
}

Long Parameter List: Parameter Object

Refactored Code:

class ReportParameters {
    String title;
    String author;
    Date date;
    Data data;
    Format format;

    // Constructor to initialize fields
    ReportParameters(String title, String author, Date date, Data data, Format format) {
        this.title = title;
        this.author = author;
        this.date = date;
        this.data = data;
        this.format = format;
    }
}

public void createReport(ReportParameters params) {
    // Use params.title, params.author, etc.
}

• Benefits: Reduces the number of parameters, clarifies the method’s purpose, and groups related data together, making the code cleaner and easier to maintain.

Long Parameter List: Method Object

• Technique: Turn the method into an object that has the original parameters as fields.

Problem Code:

public void createReport(String title, String author, Date date, Data data, Format format) {
    // Complex method body with many local variables and calculations
}

Long Parameter List: Method Object

Refactored Code:

class ReportCreator {
    private String title;
    private String author;
    private Date date;
    private Data data;
    private Format format;

    ReportCreator(String title, String author, Date date, Data data, Format format) {
        this.title = title;
        this.author = author;
        this.date = date;
        this.data = data;
        this.format = format;
    }

    public void create() {
        // Method body with access to the fields directly
    }
}

// Usage
ReportCreator creator = new ReportCreator(title, author, date, data, format);
creator.create();

• Benefits: Simplifies the original method, encapsulates the parameters and the method logic within a single cohesive class, and improves code organization and readability.

Switch Statements

• Identification: Excessive use of switch or complex if-else chains in the code.

• Example:

  switch (employee.type) {
      case COMMISSIONED:
          return calculateCommissionedPay(employee);
      case HOURLY:
          return calculateHourlyPay(employee);
      // other cases
  }

Switch Statements

• Refactoring Techniques:

  • Replace Conditional with Polymorphism: Use polymorphism to handle varying behavior based on type.

  • Replace Type Code with Subclasses: Create subclasses for each type code.

Switch Statements: Polymorphism

• Technique: Use polymorphism to handle varying behavior based on an object’s type instead of a switch or complex if-else chains.

Problem Code:

class Employee {
    Type type;

    double calculatePay() {
        switch (type) {
            case COMMISSIONED:
                return calculateCommissionedPay();
            case HOURLY:
                return calculateHourlyPay();
            // other cases
        }
    }
}

Switch Statements: Polymorphism

Refactored Code:

abstract class Employee {
    abstract double calculatePay();
}

class CommissionedEmployee extends Employee {
    double calculatePay() {
        return calculateCommissionedPay();
    }
}

class HourlyEmployee extends Employee {
    double calculatePay() {
        return calculateHourlyPay();
    }
}

// Usage:
Employee employee = new CommissionedEmployee();
double pay = employee.calculatePay();

• Benefits: Eliminates the switch statement by encapsulating the varying behavior within each subclass. This makes the code easier to extend and maintain, as new types can be added without modifying existing code.

Switch Statements: Subclasses

• Technique: Create subclasses for each type code, moving the behavior dependent on the type into these subclasses.

Problem Code:

class Employee {
    enum Type { COMMISSIONED, HOURLY, SALARIED }
    Type type;

    double calculatePay() {
        switch (type) {
            case COMMISSIONED:
                return calculateCommissionedPay();
            case HOURLY:
                return calculateHourlyPay();
            // other cases
        }
    }
}

Switch Statements: Subclasses

Refactored Code:

abstract class Employee {
    abstract double calculatePay();
}

class CommissionedEmployee extends Employee {
    double calculatePay() {
        return calculateCommissionedPay();
    }
}

class HourlyEmployee extends Employee {
    double calculatePay() {
        return calculateHourlyPay();
    }
}

class SalariedEmployee extends Employee {
    double calculatePay() {
        return calculateSalariedPay();
    }
}

// Usage:
Employee employee = new HourlyEmployee();
double pay = employee.calculatePay();

• Benefits: Each subclass clearly represents a specific type of employee and its corresponding calculation method. It adheres to the Open/Closed Principle, as new types can be added without affecting existing classes.

Switch statements can often be refactored to use more object-oriented approaches like polymorphism, making the code more flexible and easier to extend.

Feature Envy

• Identification: A method that seems more interested in a class other than the one it actually is in.

• Example:

    public class ReportGenerator {
        public void generateReport(Data data) {
            // Method body heavily using methods and fields from 'Data' class
        }
    }

Feature Envy

• Refactoring Techniques:

  • Move Method: Move the method to the class it is most interested in.

  • Extract Method: If only part of the method suffers from feature envy, extract that part.

Feature Envy : Move Method

• Technique: Move the method to the class it is most interested in.

Problem Code:

class ReportGenerator {
    // ... other methods ...
    public void generateReport(Data data) {
        System.out.println("Report Title: " + data.getTitle());
        System.out.println("Report Data: " + data.getFormattedData());
        // Several other lines interacting with 'Data' class
    }
}

class Data {
    String getTitle() { /* ... */ }
    String getFormattedData() { /* ... */ }
    // ... other methods ...
}

Feature Envy : Move Method

Refactored Code:

class ReportGenerator {
    // ... other methods ...
    public void generateReport(Data data) {
        data.printReportDetails();
    }
}

class Data {
    // ... other methods ...
    void printReportDetails() {
        System.out.println("Report Title: " + getTitle());
        System.out.println("Report Data: " + getFormattedData());
        // Moved method content here
    }
}

• Benefits: Aligns the method with the data it primarily operates on, improving cohesion and making the code more logical and easier to understand.

Feature Envy: Extract Method

• Technique: If only part of the method suffers from feature envy, extract that part.

Problem Code:

class ReportGenerator {
    public void generateReport(Data data) {
        // ... some code working with ReportGenerator's own data ...
        System.out.println("Report Data: " + data.getFormattedData());
        // ... more code working with ReportGenerator's own data ...
    }
}

class Data {
    String getFormattedData() { /* ... */ }
    // ... other methods ...
}

Feature Envy: Extract Method

Refactored Code:

class ReportGenerator {
    public void generateReport(Data data) {
        // ... some code working with ReportGenerator's own data ...
        printDataDetails(data);
        // ... more code working with ReportGenerator's own data ...
    }

    private void printDataDetails(Data data) {
        System.out.println("Report Data: " + data.getFormattedData());
        // Isolated the part that was showing feature envy
    }
}

class Data {
    // ... other methods ...
}

• Benefits: Separates the responsibilities more clearly, addressing the feature envy within the method by isolating the envious segment, making the code more modular and maintainable.

Feature Envy can lead to code that’s hard to understand and maintain because it’s not located where it logically belongs. Refactoring aims to place the code where it fits best conceptually.

Data Clumps

• Identification: Groups of data that always appear together but aren’t organized into a structure.

• Example:

    public void createCustomer(String firstName, String lastName, String street, String city, String zip) {
        // Method body
    }

Data Clumps

• Refactoring Techniques:

  • Introduce Parameter Object or Class: Group the clumped data into a single object representing the entire concept.

Data Clumps: Parameter Object or Class

• Technique: Group the clumped data into a single object representing the entire concept.

Problem Code:

class CustomerService {
    public void createCustomer(String firstName, String lastName, String street, String city, String zip) {
        // Logic to create a customer
    }
}

• Issues: The createCustomer method takes multiple parameters related to customer and address, making it cumbersome and prone to errors.

Data Clumps: Parameter Object or Class

Refactored Code:

class Customer {
    String firstName;
    String lastName;
    Address address;
}

class Address {
    String street;
    String city;
    String zip;
}

class CustomerService {
    public void createCustomer(Customer customer) {
        // Logic to create a customer
    }
}

• Benefits: Encapsulates related data into coherent structures, simplifying method signatures and promoting code reuse and clarity. This makes the code more maintainable and understandable, as well as easier to extend with new customer-related attributes or behaviors.

In this refactoring, Customer and Address classes are introduced to encapsulate the data clumps. The createCustomer method now takes a single Customer object, which includes all necessary data, making the code cleaner and more organized.

Data clumps make the code more verbose and error-prone. By introducing parameter objects or classes, you can make the code more cohesive and easier to understand.

Primitive Obsession

• Identification: Overuse of primitive types instead of small objects for simple tasks.

• Example:

  public void processDate(String date) {
      // Complex manipulation using string
  }

Primitive Obsession

• Refactoring Techniques:

  • Replace Data Value with Object: Create an object for the type of data you have.

  • Replace Array with Object: Use an object to represent a group of related data instead of an array.

Primitive Obsession: Data Value

• Technique: Create an object for the type of data you have.

Problem Code:

class User {
    private String name; // Primitive type
    private String phone; // Primitive type

    public void displayUserInfo() {
        System.out.println("Name: " + name + ", Phone: " + phone);
    }
}

Primitive Obsession: Data Value

Refactored Code:

class Phone {
    private String number;

    public Phone(String number) {
        this.number = number;
    }

    public String formatNumber() {
        // Format number (e.g., add dashes)
        return number;
    }
}

class User {
    private String name; // Still primitive type, appropriate here
    private Phone phone; // Replaced with object

    public User(String name, String phoneNumber) {
        this.name = name;
        this.phone = new Phone(phoneNumber);
    }

    public void displayUserInfo() {
        System.out.println("Name: " + name + ", Phone: " + phone.formatNumber());
    }
}

• Benefits: Encapsulates data and behavior related to phone numbers, making the code more understandable and maintainable.

Primitive Obsession: Array

• Technique: Use an object to represent a group of related data instead of an array.

Problem Code:

class UserData {
    String[] userInfo; // [0] for name, [1] for phone, [2] for address

    public void displayUserInfo() {
        System.out.println("Name: " + userInfo[0] + ", Phone: " + userInfo[1] + ", Address: " + userInfo[2]);
    }
}

Primitive Obsession: Array

Refactored Code:

class User {
    private String name;
    private String phone;
    private String address;

    public User(String name, String phone, String address) {
        this.name = name;
        this.phone = phone;
        this.address = address;
    }

    public void displayUserInfo() {
        System.out.println("Name: " + name + ", Phone: " + phone + ", Address: " + address);
    }
}

• Benefits: Each piece of data is now clearly defined, improving readability and reducing the risk of errors like incorrect array index access.

Primitive obsession can lead to complicated code that’s hard to understand and maintain. Refactoring it involves creating more meaningful and robust abstractions.

Testing and Refactoring

The Role of Testing in Refactoring

• Purpose of Testing: Confirm unchanged behavior post-refactoring.

• Continuous Testing: Implement continuous testing during refactoring.

• Test Coverage: Extensive test coverage for thorough checks.

Testing is the safety net that allows you to refactor with confidence. It ensures that as you improve the structure of the code, you don’t introduce any functional changes. Good tests check the expected behavior of the code and alert you if something goes wrong during the refactoring.

Writing Good Tests

• Good Test Traits:
  • Readable: Easily comprehensible.
  • Reliable: Yield consistent results.
  • Fast: Quick execution for development efficiency.
  • Isolated: Focus on one aspect, independent of others.
• Test Data: Use representative data that covers normal, boundary, and error conditions.

Writing good tests is an art. They should be clear and focused, testing one thing at a time. This makes it easier to identify what’s wrong when a test fails. Good tests also run quickly, allowing them to be run frequently without slowing down development.

Example Test Case and Refactoring

• Scenario: Refactoring a method to calculate discounts based on customer type.

• Before Refactoring: Complex method with multiple conditionals.

• Test Case Example:

  @Test
  public void testCalculateDiscount() {
      Customer customer = new Customer("Regular");
      double discount = order.calculateDiscount(customer);
      assertEquals(0.1, discount, "Regular customers should get a 10% discount.");
  }

  Example Test Case and Refactoring

• Refactoring: Use polymorphism to handle different customer types.

• After Refactoring: Cleaner method with customer type determining discount strategy.

This example illustrates the process of writing a test for specific functionality and then refactoring the code to improve its design. The test remains the same before and after refactoring, ensuring that the behavior of the code hasn’t changed.

Refactoring Catalog

Extract Method

• Motivation: You have a code fragment that can be grouped together.

• Mechanics: Identify the fragment, create a new method, and replace the old code with a call to the method.

• Example:

    // Before
    public void printOwing() {
        printBanner();
        //print details
        System.out.println ("name: " + _name);
        System.out.println ("amount: " + getOutstanding());
    }

Extract Method

    // After
    public void printOwing() {
        printBanner();
        printDetails(getOutstanding());
    }
    private void printDetails(double outstanding) {
        System.out.println ("name: " + _name);
        System.out.println ("amount: " + outstanding);
    }

• Benefits: Improves readability and reusability of code.

The Extract Method is one of the most common refactorings. It’s used to make the code more organized and maintainable by breaking down long methods into smaller, more focused ones.

Rename Method

• Motivation: The name of the method does not clearly describe what the method does.

• Mechanics: Change the method name and update all references to it.

• Example:

    // Before
    class Person {
        String getTelephoneNumber() {
            return officeTelephone.getTelephoneNumber();
        }
    }

Rename Method

    // After
    class Person {
        String getOfficePhoneNumber() {
            return officeTelephone.getTelephoneNumber();
        }
    }

• Benefits: Improves the clarity and readability of the code.

Renaming a method might seem trivial, but it can significantly improve the understandability of the code. A well-named method can communicate its purpose at a glance, making the code easier to read and maintain.

Inline Method

• Motivation: A method’s body is just as clear as its name, or it’s used only in a few places.

• Mechanics: Replace calls to the method with the method’s content and delete the method.

• Example:

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

Inline Method

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

• Benefits: Simplifies the code when a method is only adding unnecessary indirection.

Inlining a method is the opposite of extracting a method. It’s used when a method is not providing enough value and is only adding complexity to the code. It simplifies the code by eliminating the extra method call.

Move Method/Field

• Motivation: A method or field is more related to another class than the one it currently is in.

• Mechanics: Create a new method/field in the target class and adjust the code to reference the new location.

• Example:

    // Before
    class Account {
        private AccountType _type;
        double overdraftCharge() {
            if (_type.isPremium()) {
                // calculation
            }
            else {
                // different calculation
            }
        }
    }

Move Method/Field

    // After
    class AccountType {
        double overdraftCharge() {
            if (this.isPremium()) {
                // calculation
            }
            else {
                // different calculation
            }
        }
    }

• Benefits: Improves the organization of the code and enhances its clarity.

Moving a method or field to a more appropriate class helps to ensure that data and behavior are located where they logically belong. This enhances the clarity and cohesion of the code, making it easier to understand and maintain.

Legacy Code and Refactoring

Challenges of Legacy Code

• Definition: Legacy code often refers to code that is inherited from others or older systems.

• Common Issues:

  • Poorly documented or undocumented.

  • Tightly coupled and hard to understand.

  • Lacking tests, making changes risky.

Challenges of Legacy Code

• Understanding Legacy Code: Often the first challenge is just understanding what the code does and why.

Legacy code can be a significant obstacle to both maintaining and extending an application. It’s often seen as brittle, complex, and difficult to understand. Dealing with legacy code requires a careful approach to ensure that improvements can be made without introducing new issues.

Strategies for Refactoring Legacy Code

• Testing as a First Step: Begin with test writing for comprehension and documentation.
• Refactor in Small Steps: Implement and test small changes regularly.
• Focus on High-Impact Areas: Concentrate on frequently altered or problematic sections.

Refactoring legacy code is often about making it safer and easier to work with. It’s usually not feasible to refactor everything, so focus on making strategic improvements that will provide the most benefit. Testing, understanding, and small, deliberate changes are key strategies.

Incremental Improvement in Legacy Systems

• Continuous Refactoring: Integrate code cleanup routinely.
• Refactoring with Each Feature: Refactor with each new feature addition.
• Documentation: Update or create documentation.

In legacy systems, sweeping changes are often too risky or impractical. Instead, focus on continuous, incremental improvements. Over time, these small changes can significantly improve the overall health of the codebase. This approach also helps spread the cost and effort of refactoring over time, making it more manageable.

Netflix’s Evolution: Context & Hurdles

• Background: Transition from DVD rental to streaming due to market evolution. Inadequate monolithic codebase for the shift.

• Challenges:

  • Scalability: Limited capacity for growing subscribers and global expansion.
  • Reliability: System outages impacting user experience.

This slide sets the stage for understanding Netflix’s initial state and the imperative for change. It outlines the key challenges that drove the need for a major overhaul of their technical infrastructure and approach.

Netflix’s Transition: Key Strategies & Results

• Strategies:
  • Microservices: Enhanced scalability and development speed.
  • Cloud Migration (AWS): Improved scalability and reliability.
  • Chaos Engineering: Boosted system resilience through intentional failures.
  • Continuous Delivery: Streamlined testing and deployment.

This slide delves into the specific strategies Netflix employed to overcome their challenges, as well as the outcomes of these efforts. It highlights the transformational impact of refactoring on their ability to scale, innovate, and maintain a high-quality service.

Clean Code vs. Performance

• Trade-offs: Balancing readability and efficiency.
• Prioritization: Deciding between maintainability and speed.
• Iterative Strategy: Gradual adjustments with impact assessment.

Finding the right balance between clean code and performance is often challenging. In some cases, the cleanest code isn’t the fastest and vice versa. It’s essential to understand the priorities for your application and to take an iterative approach where you make small, measured changes and assess their impact.