Alternative Classes with Different Interfaces

Two classes do the same thing but have different signatures.

Fowler & Beck, Refactoring

Signs of Use (Symptoms)

  • EmailNotifier.send(to, msg) and SmsNotifier.dispatch(message, recipient).
  • You can’t swap implementations without modifying calling code.

Why it is bad (Consequences)

  • No Polymorphism: Cannot use them interchangeably.
  • Duplication: Similar logic, different names.

Why it happens (Root Cause)

Different developers wrote them independently, or one was copied and modified.

When it might be okay (Exceptions)

  • Rarely. External libraries you can’t control.

Explanation

Problem

Two notifiers exist. One uses send, the other uses dispatch. Both do the same thing.

The Flaw

No common interface. You can’t write code that works with “any notifier”.

Real world analogy

Two remote controls for the same TV. One says “Power”, the other says “Standby”. They do the same thing, but you have to learn both.

Refactoring Solution

  • Rename Method: Make signatures consistent.
  • Extract Superclass/Interface: Unify under a common abstraction.

Pros and Cons (of the Antipattern)

Pros (Why people do it) Cons (The price you pay)
  • Independent development
    		•
  • No interchangeability
    		•

    Comparison

    • Related Antipatterns: Duplicate Code.
    • Related Principles: Violates DIP (no common abstraction).

    Code example

    Typescript

    Bad (The Antipattern)

    Good (The Fix)

    PHP

    Good (The Fix)