Refused Bequest

Flag an inheritance edge as broken when a subclass accepts a parent's implementation but refuses part of its contract — stubbing, throwing, or silently mishandling inherited members — because that refusal is exactly the Liskov substitutability violation the is-a declaration promised not to make.

Core Idea

Refused bequest is the object-oriented code smell, named by Beck and Fowler (1999), in which a subclass inherits methods, fields, or obligations it does not want and honours only by throwing NotSupportedException, returning null, or leaving bodies empty. It uses inheritance to grab the implementation while rejecting the contract. Measured against the Liskov Substitution Principle the subclass is not substitutable: the inheritance edge declared "is-a," but the subclass contradicts it for the refused members.

Scope of Application

Lives wherever an extends edge declares "is-a" while the subclass contradicts the declared contract for some members.

• Class hierarchies in OO languages — the canonical Square extends Rectangle refusing independent setters.
• Framework subclassing — a widget stubbing dozens of base-class lifecycle hooks it does not use.
• Object-relational mapping — a value object inheriting entity machinery it cannot honour.
• GUI control hierarchies — a read-only control refusing inherited edit, focus, and input methods.
• Adjacent type-system constructs — the same pattern in typeclass hierarchies and schema extension.

Clarity

Naming refused bequest converts a reviewer's diffuse discomfort into a pointable diagnostic: the empty override and the NotSupportedException are the visible signature of one defect. Its clarifying move drives a wedge between what is inherited and what the subclass can honour, making the gap itself the object of attention and explaining why the smell is a correctness problem — an LSP violation. It also sharpens the why, distinguishing subtype classification from mere implementation reuse and routing to a named fix.

Manages Complexity

Reviewing a hierarchy otherwise means re-deriving a bundle of separate worries for every subclass. Refused bequest compresses the cluster to one per-member question — can the subclass honour this inherited member as the parent's contract requires? — with the throw, null, and empty override as four spellings of "no." The reviewer tracks a single tally of refused members per edge, and substitutability reads straight off whether that set is empty, routing the fix on a two-way branch.

Abstract Reasoning

The smell licenses a diagnostic move reading the refusal signature as direct proof that substitutability fails, a predictive move forecasting where the latent fault surfaces (clients holding the subclass through a superclass-typed reference), a root-cause classification separating subtype classification from implementation reuse, and a deterministic remedy-routing move selecting Replace Inheritance with Delegation or Extract Superclass by the edge's intent.

Knowledge Transfer

Within OO programming refused bequest transfers as mechanism, unchanged across language families, inheritance flavors, and idiomatic cases, because each is the same substrate — an is-a edge whose subclass contradicts the contract. Beyond OO the transfer is mostly metaphor: a role or bylaw "inheriting" duties it cannot meet borrows the shape while dropping the LSP-and-refactoring apparatus. The genuinely portable structure travels via the parents classification, contract, liskov_substitution_principle, and interface_mismatch — a classification that bequeaths a contract its member cannot honour — not the named craft smell.

Relationships to Other Abstractions

Current abstraction Refused Bequest Domain-specific

Parents (3) — more general patterns this builds on

• Refused Bequest is a kind of Code Smell Domain-specific

  Refused Bequest is the code-smell species whose stubs, throws, or ignored inherited members provide defeasible evidence that inheritance was used for reuse despite a broken subtype contract.

• Refused Bequest is a kind of Interface Mismatch Prime

  Refused Bequest is the object-oriented interface mismatch in which a subtype's offered behavior fails the supertype contract clients are entitled to require.

• Refused Bequest presupposes Liskov Substitution Principle Domain-specific

  Refused Bequest presupposes LSP because the smell is precisely a subclass refusing inherited obligations that substitutability requires it to honor.

Hierarchy paths (13) — routes to 8 parentless roots

• Refused Bequest → Code Smell → Evidence → Provenance → Traceability → Observability

Show alternative paths (12)

Neighborhood in Abstraction Space

Refused Bequest sits in a sparse region of the domain-specific corpus (81^st percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Overgeneralization & Rule Misapplication (5 abstractions)

Nearest neighbors

• Liskov Substitution Principle — 0.86
• Primitive Obsession — 0.83
• Lazy Class — 0.82
• Declared Equivalence Mapping — 0.82
• Data Class — 0.82

Computed from structural-signature embeddings · 2026-07-12