0Pricing
Clean Architecture & Design Patterns in Practice · 课时

使用设计模式重构

学习如何应用恰当的设计模式,系统地重构现有代码库,以改善结构和可维护性。

使用设计模式重构 是 CoddyKit 上的免费 Clean Architecture & Design Patterns in Practice 课时。 这是第 3 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Clean Architecture & Design Patterns in Practice 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Clean Architecture & Design Patterns in Practice 课程共包含 4 节课。

本课时的部分内容尚未翻译,以英文显示。

Refactoring with Design Patterns

What is refactoring? It's about improving existing code's structure without changing its external behavior. Why bring design patterns into it? Patterns offer proven, reusable solutions to common design problems, making your refactoring more systematic and effective. This leads to clearer, more maintainable, and extensible code.

Spotting Code Smells

Before you refactor, you need to know what to refactor. Code smells are indicators that something might be wrong in your code's design. They aren't bugs, but they can lead to them or make code harder to change.

  • Long Method: A method that does too much.
  • Large Class: A class with too many responsibilities.
  • Duplicate Code: The same code logic appearing in multiple places.
  • Conditional Complexity: Too many if/else or switch statements.

Systematic Refactoring Steps

Refactoring should be a disciplined process, not a rushed rewrite. Here’s a simple workflow:

  1. Identify a Code Smell: Find an area in your code that could be improved.
  2. Choose a Design Pattern: Select a pattern that addresses the identified smell.
  3. Apply the Pattern: Make small, incremental changes, ensuring tests pass at each step.
  4. Test Thoroughly: Verify that the external behavior remains unchanged.

Remember: "Red, Green, Refactor" is a powerful mantra!

Strategy for Conditional Logic

Let's tackle a common smell: methods with extensive conditional logic (many if/else or switch statements). This makes code hard to read, test, and extend. The Strategy Pattern helps by encapsulating varying behaviors into separate, interchangeable objects.

Consider a basic calculator:

public class SimpleCalculator {
  public int calculate(String operation, int a, int b) {
    if ("add".equals(operation)) {
      return a + b;
    } else if ("subtract".equals(operation)) {
      return a - b;
    } else if ("multiply".equals(operation)) {
      return a * b;
    }
    throw new IllegalArgumentException("Unknown operation");
  }

  public static void main(String[] args) {
    SimpleCalculator calc = new SimpleCalculator();
    System.out.println("Add: " + calc.calculate("add", 5, 3));
    System.out.println("Subtract: " + calc.calculate("subtract", 5, 3));
  }
}

Refactoring to Strategy

To refactor the calculator, we'll introduce an Operation interface and specific strategy classes for each operation. The Calculator then uses an instance of an Operation strategy. This makes it easy to add new operations without modifying the Calculator class.

interface Operation {
  int execute(int a, int b);
}

class AddOperation implements Operation {
  @Override
  public int execute(int a, int b) {
    return a + b;
  }
}

class SubtractOperation implements Operation {
  @Override
  public int execute(int a, int b) {
    return a - b;
  }
}

public class RefactoredCalculator {
  private Operation operation;

  public void setOperation(Operation operation) {
    this.operation = operation;
  }

  public int calculate(int a, int b) {
    if (operation == null) {
      throw new IllegalStateException("Operation not set");
    }
    return operation.execute(a, b);
  }

  public static void main(String[] args) {
    RefactoredCalculator calc = new RefactoredCalculator();
    
    calc.setOperation(new AddOperation());
    System.out.println("Add: " + calc.calculate(5, 3));
    
    calc.setOperation(new SubtractOperation());
    System.out.println("Subtract: " + calc.calculate(5, 3));
  }
}

State Pattern for Behavior Changes

Another common code smell is an object whose behavior changes based on its internal state, often managed by many if/else or switch statements within its methods. The State Pattern allows an object to alter its behavior when its internal state changes, making it appear as if the object changed its class.

Let's look at a traffic light:

public class SimpleTrafficLight {
  private String currentState;

  public SimpleTrafficLight() {
    this.currentState = "RED"; // Initial state
  }

  public void change() {
    if ("RED".equals(currentState)) {
      currentState = "GREEN";
      System.out.println("Traffic light is now GREEN.");
    } else if ("GREEN".equals(currentState)) {
      currentState = "YELLOW";
      System.out.println("Traffic light is now YELLOW.");
    } else if ("YELLOW".equals(currentState)) {
      currentState = "RED";
      System.out.println("Traffic light is now RED.");
    }
  }

  public static void main(String[] args) {
    SimpleTrafficLight light = new SimpleTrafficLight();
    light.change(); // GREEN
    light.change(); // YELLOW
    light.change(); // RED
  }
}

Refactoring to State

With the State pattern, we'll define an interface for the traffic light's state (TrafficLightState) and concrete classes for each state (RedState, GreenState, YellowState). The TrafficLight class will hold a reference to its current state object and delegate behavior to it. This cleanly separates state-specific behavior.

interface TrafficLightState {
  void change(TrafficLight context);
}

class RedState implements TrafficLightState {
  @Override
  public void change(TrafficLight context) {
    System.out.println("Traffic light is now GREEN.");
    context.setState(new GreenState());
  }
}

class GreenState implements TrafficLightState {
  @Override
  public void change(TrafficLight context) {
    System.out.println("Traffic light is now YELLOW.");
    context.setState(new YellowState());
  }
}

class YellowState implements TrafficLightState {
  @Override
  public void change(TrafficLight context) {
    System.out.println("Traffic light is now RED.");
    context.setState(new RedState());
  }
}

public class TrafficLight {
  private TrafficLightState currentState;

  public TrafficLight() {
    this.currentState = new RedState(); // Initial state
  }

  public void setState(TrafficLightState state) {
    this.currentState = state;
  }

  public void change() {
    currentState.change(this);
  }

  public static void main(String[] args) {
    TrafficLight light = new TrafficLight();
    light.change(); // GREEN
    light.change(); // YELLOW
    light.change(); // RED
  }
}

Selecting the Right Pattern

Deciding which pattern to apply can be challenging. Here are some common smells and suitable patterns:

  • Conditional Complexity (if/else, switch): Often refactored with Strategy, State, or Command.
  • Duplicate Code: Can often be solved by Factory Method, Template Method, or extracting common logic into a superclass.
  • Tight Coupling: Facade, Mediator, Observer can reduce dependencies.
  • Incompatible Interfaces: Adapter pattern is perfect for this.
  • Adding Functionality Dynamically: Decorator pattern.

Why Refactor with Patterns?

Systematically applying design patterns during refactoring provides significant advantages:

  • Improved Readability: Patterns give a common vocabulary and structure.
  • Enhanced Maintainability: Changes are localized and easier to implement.
  • Increased Extensibility: New features can often be added without modifying existing code (Open/Closed Principle).
  • Better Testability: Decoupled components are easier to unit test.

It transforms messy code into a well-structured, robust system.

Refactoring Quiz

Imagine you have a class that handles various report generation formats (PDF, CSV, XML) using a large switch statement. You want to make it easy to add new formats without changing the core report generator class.

Recap: Refactor with Patterns

Today, we learned how to approach refactoring systematically using design patterns. We explored common code smells and saw how patterns like Strategy and State can transform complex conditional logic into cleaner, more extensible designs.

Remember, refactoring is an ongoing process that, when guided by design patterns, significantly improves your codebase's quality and adaptability.

常见问题解答

「使用设计模式重构」课时是免费的吗?

是的 — 「使用设计模式重构」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Clean Architecture & Design Patterns in Practice 课程的其余内容,请升级到 CoddyKit PRO。 Clean Architecture & Design Patterns in Practice 课程共包含 4 节课。

「使用设计模式重构」这节课中我会学到什么?

学习如何应用恰当的设计模式,系统地重构现有代码库,以改善结构和可维护性。 你通过在浏览器中直接运行的动手代码来练习 Clean Architecture & Design Patterns in Practice,全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Clean Architecture & Design Patterns in Practice 需要有经验吗?

无需任何先前经验。CoddyKit 上的 Clean Architecture & Design Patterns in Practice 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 3 节课,共 4 节。

「使用设计模式重构」课时需要多长时间?

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。

我能在这节 Clean Architecture & Design Patterns in Practice 课中编写并运行代码吗?

能。每节 Clean Architecture & Design Patterns in Practice 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 深入理解依赖倒置
  2. 实践接口隔离
  3. 使用设计模式重构
  4. 单一职责与开闭原则精通
← 返回 Clean Architecture & Design Patterns in Practice