Skip to main content

Refactoring Code

Extract Method​

Naming Conventions​

  • the method is named what it does
  • (some submethods for saying how it's done if needed)
  • one word per concept
  • one level of abastraction per function

The "extract method" refactoring is a great tool to address several code smells that can hinder readability and maintainability. Here are some common code smells where using extract method can be beneficial:

  • Duplicate Code: If you find yourself copying and pasting the same block of code in multiple places, that's a prime candidate for extraction. Extract the shared logic into a separate method with a clear name, promoting code reuse and reducing redundancy.
  • Long Method: A method that stretches on for dozens of lines can be hard to understand and follow. If you have a large method with a well-defined sub-task within it, consider extracting that sub-task into its own method. This improves readability and makes the code easier to reason about.
  • God Class: A "god class" tries to do too much and contains a massive amount of code. If you have a method within such a class that handles a specific functionality, extract it into a separate class or a helper class specific to that functionality. This promotes better organization and reduces complexity.
  • Conditional Logic Clutter: If a method has a complex conditional block that's hard to follow, consider extracting the logic within the conditional into a separate method with a descriptive name. This improves readability and makes the decision-making process clearer.
  • Large Loops: Similar to long methods, loops that are overly complex can benefit from extraction. If a loop has a well-defined sub-task within it, consider creating a separate method to handle that specific task. This improves code organization and maintainability.

By applying the "extract method" refactoring to these code smells, you can create cleaner, more concise, and easier to understand code.

From Switch Statements to Polymorphism (base class aka interface)​

Switch statements and polymorphism are related concepts, but they don't directly achieve the same thing. Here's a breakdown:

Switch Statements:

  • Function: A switch statement allows you to execute different code blocks based on the value of a variable. It compares the variable to different cases and jumps to the corresponding code block.
  • Limitation: Switch statements can become inflexible and hard to maintain as the number of cases grows. Adding new cases requires modifying the existing switch statement.

Polymorphism:

  • Concept: Polymorphism is a programming principle that allows objects of different classes to respond to the same method call in different ways. This means the behavior depends on the actual object type at runtime.
  • Benefits: Polymorphism promotes code flexibility and maintainability. You can add new functionality by creating new subclasses without modifying existing code.

Refactoring Switch Statements with Polymorphism:

In some cases, you can refactor a complex switch statement using polymorphism. Here's the idea:

  1. Identify a Common Interface: Define an interface or base class that specifies a method for the desired behavior (what the switch statement was doing).
  2. Create Subclasses: Implement the interface/base class in different subclasses, each subclass providing its specific implementation of the method.
  3. Replace Switch with Polymorphism: Instead of using a switch statement, use the interface/base class as a reference variable. At runtime, the actual object type will determine which subclass's implementation of the method is called.

This refactoring improves code maintainability and flexibility. Adding new behaviors becomes easier – you just create a new subclass implementing the interface.

However, it's important to note that not all switch statements are good candidates for refactoring with polymorphism. Simple switch statements might be clearer and more efficient to leave as-is. The decision depends on the complexity of the logic and the potential for future changes.