Replace Type Code with Subclasses

Refactoring & Technical Debt

Meaning

Replace a type code field with subclasses, where each subclass implements the behavior associated with a particular type code value. This eliminates repetitive conditional statements that depend on the type code, reducing duplication and the risk of missing cases when new types are added. It is applied when a class uses a field or variable to indicate a type and selects behavior via switch or if‑else chains on that field.

Primary Function

Refactoring

Communicative Purpose

Eliminates conditional logic based on type codes by using polymorphism.

Pattern

Replace type code field with subclasses, each overriding behavior.

Função primária

Refactoring

Propósito comunicativo

Eliminates conditional logic based on type codes by using polymorphism.

Situações de gatilho

Software engineering: a class uses an integer typeCode field to choose behavior in a method with a switch statement. Software engineering: adding a new type requires locating all switch statements and adding a new case, violating open‑closed principle. Software engineering: runtime errors occur when a new type code value is introduced but not handled in existing conditionals.

Contextos

Object‑oriented codebases, legacy Java/C# applications, refactoring catalogs.

Padrão

Replace type code field with subclasses, each overriding behavior.

Colocados típicos

Polymorphism
Switch statements
Factory methods
Open‑closed principle.

Substituições comuns

Use the Strategy pattern (more flexible but adds indirection)
Keep the type code with a map of functions (simpler but less type‑safe)
Use an enum with associated behavior (language‑specific).

Erros comuns

Failing to declare the base class method as abstract, leading to subclasses that do not implement the behavior → runtime errors when the method is called. Not updating all clients that reference the type code field directly, causing inconsistent behavior after refactoring. Creating too many subclasses for minor variations, resulting in unnecessary complexity and class explosion.

Similar / contraste

State pattern: encapsulates state‑dependent behavior in objects rather than type codes. Strategy pattern: defines a family of interchangeable algorithms accessed via composition. Extract Subclass: isolates a subset of functionality into a subclass without replacing a type code.

Interferências

Coming from C: may use enum tags instead of subclasses — C lacks inheritance, so consider using function pointers or structs with callbacks. Coming from JavaScript: may prefer object maps over classes — JavaScript’s prototypal inheritance can achieve similar polymorphism with less ceremony.

Família do chunk

Extract Subclass
Replace Conditional with Polymorphism
Introduce Null Object

Nuance

Do not use this when the type code is truly static and never extended — simple switches may be clearer. Performance impact is negligible; the indirection of virtual method calls is usually offset by cleaner code and faster maintenance. Ensure that all subclasses are placed in the same module or package to avoid circular dependencies when the base class references them.

Efeito pragmático

Enables easier extension and reduces bugs from missing case statements, making the codebase more robust to change.

Dica de memória

Think of a type code as a lazy receptionist who routes visitors based on a badge number; replacing it with subclasses is like giving each visitor type their own dedicated host who knows exactly what to do.

Nota

Ensure that any serialization or persistence mechanisms are updated to handle the new subclass hierarchy, otherwise deserialization may fail.

Upgrade path

Apply the State pattern for more complex state‑dependent behavior.

Frequência: MediumFormulaicidade: FlexibleTipo de construção: conceptPrioridade de aquisição: Active recallPrioridade de output: BothTag de espaçamento: Medium-term

Examples

public class Shape { private int type; // 1=Circle, 2=Square public void draw() { switch (type) { case 1: drawCircle(); break; case 2: drawSquare(); break; } } private void drawCircle() { /* ... */ } private void drawSquare() { /* ... */ } }

public abstract class Shape { public abstract void draw(); } public class Circle extends Shape { @Override public void draw() { /* draw circle */ } } public class Square extends Shape { @Override public void draw() { /* draw square */ } }

public class Renderer { private List<Shape> shapes; public void renderAll() { for (Shape s : shapes) { s.draw(); // polymorphic call, no type code needed } } }