This interface has twelve methods and every implementation throws UnsupportedOperationException for four of them. What went wrong, and how would you fix it?

Two principles are failing at once

The visible failure is interface segregation: callers depend on methods they do not use, so a change to the export half of the interface forces recompilation and retesting on classes that only ever read. That is the cost usually quoted, and on its own it sounds like tidiness.

The more serious failure is substitutability. An interface is a promise that any implementation can be used wherever the type is declared, and an implementation that throws on a third of the contract breaks that promise. The practical consequence is that callers start asking which concrete type they hold, either explicitly or by catching the exception, and once that happens the interface has stopped providing polymorphism and is only providing a shared name. You have paid for an abstraction and are getting the coupling of a concrete dependency plus a runtime failure mode.

The cause is almost always the same. The interface was extracted by taking the union of the methods the existing classes happened to have, rather than by asking what any single caller needs in order to do its job. Union-derived interfaces grow every time an implementation is added, which is the diagnostic to remember: an interface that changes whenever a new implementer appears is being written from the wrong end.

Group by client, not by class

The refactoring is driven from the call sites. For each place the interface is used, list the methods that call site actually invokes. Those lists cluster, and the clusters are the real interfaces — the roles the type plays for somebody.

A document store that has grown twelve methods usually turns out to serve three separate roles: readers that fetch and search, writers that store and delete, and an administrative path that reindexes and reports statistics. Those become DocumentReader, DocumentWriter and IndexMaintenance. The read-only implementation implements the first and nothing else, so its inability to write is now expressed in the type system instead of at runtime, and a caller that only reads cannot accidentally be handed something that mutates.

A class may implement several of these, and the concrete production class probably implements all three. That is not a failure of the split. The point was never to fragment the implementations, it was to narrow what each caller depends on, and the same object can present three faces to three collaborators.

Two guards keep this from going too far. One method per interface is not the goal; methods that a caller always uses in one unit of work belong together, and splitting them multiplies parameters and names without reducing any real coupling. And a split that leaves every caller depending on all the pieces has bought nothing except more files, which is the honest signal that the interface was cohesive after all and the throwing methods are a different problem.

Which alternatives are honest and which are not

Three other fixes get proposed, and only some of them are defensible.

Capability queries — an isMutable() that callers check before calling — are honest in that nothing lies, and they push branching into every caller and leave a race between the check and the call. Acceptable for a library that genuinely must expose heterogeneous implementations behind one type, poor as a first choice in your own code, where the type system can carry the distinction for free.

A no-op default implementation is the dangerous one. Replacing a thrown exception with an empty method body converts a loud failure into silent data loss: the caller believes the document was stored, nothing was stored, and nothing anywhere records that. A no-op is only correct where doing nothing is a genuine, documented semantic — a metrics recorder that discards, a cache that chooses not to retain — never where it fakes a capability the object lacks.

Default methods on the interface are for adding convenience over existing behaviour, so that adding a method does not break implementers. Using them to supply a plausible-looking body for an operation the implementation cannot perform is the same mistake as the no-op, dressed in newer syntax.

When optional operations are a deliberate trade

It is worth knowing that this exact design exists on purpose in the Java collections library, where mutating methods are documented as optional and the immutable implementations throw UnsupportedOperationException. That was a considered decision: one hierarchy that every collection in the language shares, at the price of a contract with holes in it, taken at a time when the alternative was several parallel hierarchies and no interoperability between them.

The reason it is tolerable there is that the holes are documented as part of the specification, the exception is the specified behaviour rather than an accident, and the callers are the whole world rather than a codebase you control. None of those conditions holds for an internal interface with three implementations, where you can simply split it. So citing the JDK as precedent is a weak defence of your own fat interface, and knowing why the trade was made there is a much stronger answer than either praising or condemning it.

Doing it on an interface others implement

If the interface is published, the split is a migration rather than an edit. Introduce the narrow interfaces first and have the wide one extend them, which is source-compatible for everybody: existing implementers still satisfy it, existing callers still compile. Then move call sites to the narrowest interface each one needs, one at a time, which is where the benefit is actually realised. Only once nothing depends on the wide type does it get deprecated and eventually removed.

That sequence matters because it makes the change reversible at every step, and because it lets you stop early if the new grouping turns out to be wrong — which you will only discover by trying to move real callers onto it.

An implementation that throws for part of its interface has told you the interface belongs to nobody. Derive interfaces from what individual callers need, and let a class implement several, rather than making every caller depend on the union of everything anybody does.