Why are long instanceof / type-check chains often considered a design smell, and what should you reach for instead?

## What the smell looks like ```java double area(Shape s) { if (s instanceof Circle c) return Math.PI * c.r() * c.r(); else if (s instanceof Square q) return q.side() * q.side(); else if (s instanceof Rect r) return r.w() * r.h(); else throw new IllegalArgumentException("unknown shape"); } ``` This works, but it concentrates *per-type* knowledge in one external method. ## Why it's a problem - **Open/Closed Principle (OCP)** says code should be open to extension but closed to modification. Here, adding `Triangle` forces editing this method — and any *other* instanceof chain over `Shape` scattered across the codebase. You must hunt them all down. - **Silent gaps**: forget a branch and you get a runtime exception or wrong default instead of a compile error. - **Cohesion**: a shape's area logic arguably belongs *with* the shape, not in a distant utility. (Defining terms: *polymorphism* = the ability to call one method name and have the right type-specific implementation run; *subtype* = a more specific type; *cohesion* = keeping related things together.) ## Fix 1: Polymorphism (the classic OO answer) Put an abstract method on the base type and override it: ```java interface Shape { double area(); } record Circle(double r) implements Shape { public double area(){ return Math.PI*r*r; } } record Square(double side) implements Shape { public double area(){ return side*side; } } // area(s) becomes just s.area(); ``` Adding `Triangle` now means adding one class — no existing code changes. Behavior lives with the data. ## Fix 2: Visitor pattern (when behavior must stay outside) Sometimes the operation doesn't belong on the type (e.g. you can't or shouldn't add a `toJson()`/`render()` to every shape, especially for types you don't own). The **visitor pattern** lets you add operations externally while still dispatching by type, trading the instanceof chain for double dispatch — at the cost of boilerplate. ## Fix 3 (modern Java): sealed types + pattern-matching switch Since Java 17 (sealed) and 21 (switch patterns), you can declare a **closed** hierarchy and let the compiler enforce completeness: ```java sealed interface Shape permits Circle, Square, Rect {} double area(Shape s) { return switch (s) { // no default needed case Circle c -> Math.PI * c.r() * c.r(); case Square q -> q.side() * q.side(); case Rect r -> r.w() * r.h(); }; } ``` Because `Shape` is **sealed** (its permitted subtypes are fixed and known), the switch is checked for **exhaustiveness**: if you add `Triangle` to `permits` and forget the case, the code **won't compile**. This combines the externalized behavior of the instanceof chain with compile-time safety — ideal for *data-oriented* code where the type set is closed and behaviors are many. ## When instanceof is perfectly fine instanceof is not banned — it's the *chains* that smell. Legitimate uses: - **`equals(Object)`** — you must accept `Object` and test type. - **Boundaries**: deserialization, reflection, framework callbacks, interop with types you don't control. - **A single, local check** — one `instanceof` to handle a special case is fine. - **Sealed + switch** is itself instanceof-style dispatch, just made safe. ## Decision guide - Behavior belongs on the type, hierarchy is open → **polymorphism**. - Behavior is external, hierarchy is open, many operations → **visitor**. - Hierarchy is **closed/known**, data-oriented, want compiler-checked completeness → **sealed + pattern switch**. - One-off / boundary check → a plain instanceof is fine.