0Pricing
Clean Architecture & Design Patterns in Practice · 강의

디자인 패턴을 활용한 리팩터링

적절한 디자인 패턴을 적용해 기존 코드 기반을 체계적으로 리팩터링하고 구조와 유지 보수성을 개선하는 방법을 배웁니다.

디자인 패턴을 활용한 리팩터링은(는) CoddyKit의 무료 Clean Architecture & Design Patterns in Practice 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 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.

자주 묻는 질문

“디자인 패턴을 활용한 리팩터링” 강의는 무료인가요?

네 — “디자인 패턴을 활용한 리팩터링” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Clean Architecture & Design Patterns in Practice 강의 전체를 잠금 해제할 수 있습니다. Clean Architecture & Design Patterns in Practice 강의에는 총 4개의 강의가 포함되어 있습니다.

“디자인 패턴을 활용한 리팩터링”에서 뭘 배우나요?

적절한 디자인 패턴을 적용해 기존 코드 기반을 체계적으로 리팩터링하고 구조와 유지 보수성을 개선하는 방법을 배웁니다. 브라우저에서 직접 실행하는 실습 코드로 Clean Architecture & Design Patterns in Practice을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Clean Architecture & Design Patterns in Practice을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Clean Architecture & Design Patterns in Practice은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“디자인 패턴을 활용한 리팩터링” 강의는 얼마나 걸리나요?

대부분의 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(으)로 돌아가기