Refactorisation avec des modèles de conception
Apprenez à refactoriser systématiquement des bases de code existantes en appliquant les modèles de conception appropriés afin d'améliorer leur structure et leur maintenabilité.
Refactorisation avec des modèles de conception est une leçon Clean Architecture & Design Patterns in Practice gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Clean Architecture & Design Patterns in Practice, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Clean Architecture & Design Patterns in Practice comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
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/elseorswitchstatements.
Systematic Refactoring Steps
Refactoring should be a disciplined process, not a rushed rewrite. Here’s a simple workflow:
- Identify a Code Smell: Find an area in your code that could be improved.
- Choose a Design Pattern: Select a pattern that addresses the identified smell.
- Apply the Pattern: Make small, incremental changes, ensuring tests pass at each step.
- 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.
Questions Fréquemment Posées
La leçon « Refactorisation avec des modèles de conception » est-elle gratuite ?
Oui — le texte complet de « Refactorisation avec des modèles de conception » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Clean Architecture & Design Patterns in Practice, passe à CoddyKit PRO. Le cours Clean Architecture & Design Patterns in Practice comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Refactorisation avec des modèles de conception » ?
Apprenez à refactoriser systématiquement des bases de code existantes en appliquant les modèles de conception appropriés afin d'améliorer leur structure et leur maintenabilité. Tu pratiques Clean Architecture & Design Patterns in Practice avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Clean Architecture & Design Patterns in Practice ?
Aucune expérience préalable n'est requise. Clean Architecture & Design Patterns in Practice sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.
Combien de temps prend la leçon « Refactorisation avec des modèles de conception » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Clean Architecture & Design Patterns in Practice ?
Oui. Chaque leçon Clean Architecture & Design Patterns in Practice inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Approfondissement de l'inversion des dépendances
- Ségrégation des interfaces en pratique
- Refactorisation avec des modèles de conception
- Maîtriser la responsabilité unique et l’ouverture à l’extension