An interface has an `add(item)` method, and one implementation overrides it to throw an "operation not supported" error (as immutable collections often do). Is that a Liskov Substitution violation, and what are the alternatives?

## What exactly is broken The Liskov Substitution Principle says a subtype must be usable anywhere its supertype is expected without breaking client code. Client code here was written against an interface whose `add(item)` is documented (or reasonably understood) as: *precondition* — the item is valid; *postcondition* — after return, the collection contains the item. An implementation that throws "unsupported operation" delivers **none** of the postcondition and introduces a failure mode the client was never told about. Framed either way it's the same defect: - **Postcondition weakening**: the promised effect doesn't happen, and an undeclared exception appears instead. - **Precondition strengthening to `false`**: there is literally no input for which the operation succeeds, so the implementation demands infinitely more of the caller than the interface did. Because signatures match, no compiler, linter, or type-checker flags it. The defect is discovered when an immutable instance is passed into a code path that mutates — often far from where the substitution happened, in production, at an unrelated call site. ## Why it happens anyway (the real-world defence) This pattern is everywhere: `java.util.Collections.unmodifiableList`, `Arrays.asList` (fixed-size), many framework "read-only view" wrappers, and `Iterator.remove` as an "optional operation". The defence usually given: 1. **Legacy interface width.** The interface was designed before read-only views existed, and splitting it would break every consumer. Optional operations were the cheapest compatible retrofit. 2. **Combinatorial explosion of interfaces.** Fully segregating every capability (readable / appendable / removable / sortable / fixed-size / thread-safe…) can multiply types uncomfortably. 3. **The contract was explicitly widened.** If the interface documents "add is an *optional* operation; implementations that don't support it throw UnsupportedOperationException", then throwing is technically compliant — the promise was always weak. This is precisely how Java's Collections Framework words it. That last point is the important nuance: **LSP compliance is relative to the documented contract.** You can always make a violation "legal" by weakening the base contract — but you pay for it in every client, which now must either handle the failure, check a capability flag, or gamble. The interface stops being useful for reasoning; "I have a List" no longer tells you what you can do with it. Most reviewers judge optional operations as a legacy compromise, not a design to imitate. ## Alternatives, ranked **1. Interface segregation (preferred).** Model capability in the type system: ``` interface ReadableCollection { size(); contains(x); iterate() } interface MutableCollection : ReadableCollection { add(x); remove(x) } ``` Immutable types implement only `ReadableCollection`. Any function that needs to mutate declares `MutableCollection`, and the mismatch becomes a **compile error at the wiring point** rather than a runtime crash deep inside a request. Kotlin (`List` vs `MutableList`), C# (`IReadOnlyList<T>` vs `IList<T>`), and Scala (`immutable` vs `mutable` packages) all take this route — the direct lesson learned from Java's optional operations. This is the LSP↔ISP link: an over-broad interface *forces* implementations into violations. **2. Make the operation total by returning a new value.** In a persistent/functional style, `add(item): Collection` returns a new collection and mutates nothing. Every implementation — mutable or immutable — can satisfy that contract honestly. Cost: allocation per operation (mitigated by structural sharing in persistent data structures) and a different calling style (`c = c.add(x)`), plus the trap that callers ignoring the return value silently lose data. **3. Explicit capability query.** Keep one interface but add `supportsAdd(): Boolean` (or a `capabilities` set) and document the failure as part of the contract. Now the failure is honest and testable, but every caller carries a branch, and forgetting the check is still a runtime crash. Useful for genuinely dynamic plugin systems where capabilities are discovered at runtime, e.g. drivers or file systems. **4. Fail early, at construction/wiring.** If a component requires a mutable collection, validate at construction or dependency-injection time rather than at the moment of use. Doesn't fix the contract, but converts a late random failure into an immediate startup failure. **5. Null Object / no-op** — *usually wrong here.* Making `add` silently do nothing avoids the exception but replaces a loud failure with silent data loss, which is strictly worse for a write operation. A no-op is only acceptable where the operation is genuinely advisory (e.g. a metrics sink, a cache hint). ## How to detect it - Grep for "unsupported"/"not supported" throws inside overrides. - Look for client code doing runtime type checks or `try { add } catch (Unsupported)`. - Contract tests: run the interface's shared behavioural suite against every implementation; a throwing implementation fails immediately — which tells you either the implementation is wrong or the interface is too wide. ## Edge cases - **Read-only *views* over mutable data** are additionally treacherous: the view forbids writes but can still change underneath the holder when the backing collection is mutated elsewhere, breaking the invariant clients infer from "unmodifiable". - **Fixed-size vs immutable** are different capabilities: a fixed-size list allows `set` but not `add`, which is why one boolean flag rarely captures the truth. - **Thread-safety** is the same problem in another dimension: swapping a synchronized implementation for an unsynchronized one weakens a guarantee clients depended on, with no signature change. - **Remote/plugin implementations** may be unable to support an operation for genuinely external reasons; there, an explicit capability contract (option 3) is the honest design, not a compromise.