Polymorphism

Software Engineering / 11 Sep 2026 / 7 min read

Replacing Type Branches with Polymorphism

Replacing Type Branches with Polymorphism A type-based switch can be perfectly clear. Trouble starts when the same cases appear across several operations. Adding one new type then means editing pricing, validation, formatting, scheduling, and other branches in separate places. The type list has become a change axis, but the code still represents it as scattered conditionals. Replacing type branches with polymorphism moves behavior for each variant behind a shared contract. Callers ask for an operation without selecting the implementation themselves. This can concentrate related rules and reduce repeated branching, but it also introduces more types and indirection. The refactoring pays off only when that trade is useful.

Software Engineering Refactoring

Software Engineering / 10 Sep 2026 / 8 min read

Replace Conditional with Polymorphism When Branches Represent Types

Replace Conditional with Polymorphism When Branches Represent Types A conditional isn’t a design problem just because it has several branches. Sometimes if or switch is the clearest way to express a decision. Trouble starts when the same type-based decision appears in several places and every new variant requires editing all of them. Replace Conditional with Polymorphism is a refactoring that moves variant-specific behavior behind a common operation. Instead of asking an object what kind it is and then deciding what to do, callers ask it to perform the behavior directly.

Software Engineering Refactoring

Software Engineering / 06 Sep 2026 / 8 min read

Replacing Behavior Switches with Polymorphism

A switch statement is not a design problem by itself. When a program has a small, stable set of cases, one explicit conditional can be easier to read than a hierarchy of types. Trouble starts when the same type distinction controls behavior in several places. Adding one new case then means finding every switch that knows about that type. Missing one produces a system where the new case works in some operations but not others.

Software Engineering Refactoring

Software Engineering / 05 Sep 2026 / 7 min read

Replacing Repeated Type Conditionals with Polymorphism

A type-based switch can be the simplest way to express a small rule. The trouble starts when the same distinction appears in several places. Pricing checks whether an order is standard or express. Delivery estimates check the same thing. Cancellation rules do too. Adding a new order type then means finding every branch that knows the list of types. The problem is not the switch syntax itself. The problem is distributed knowledge: several callers know which variants exist and which behavior belongs to each one.

Software Engineering Software Design

Python / 03 Sep 2026 / 10 min read

Use Single Dispatch for Type-Based Behavior in Python

A function sometimes needs to perform the same conceptual operation for several unrelated Python types. The straightforward solution is usually an if chain: def format_value(value): if isinstance(value, str): return value if isinstance(value, int): return str(value) if isinstance(value, dict): return ", ".join(f"{key}={item}" for key, item in value.items()) raise TypeError(f"unsupported type: {type(value).__name__}") This is perfectly reasonable when the set of supported types is small and unlikely to grow.

Python Single Dispatch