How do you decide whether inheritance is appropriate, and why is sharing some fields not enough to justify an is-a relationship?

Inheritance, is-a relationships, and substitutability

Uses inheritance only for stable behavioral subtyping and tests whether derived objects preserve the promises callers rely on.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I use inheritance only when the subtype can preserve the base type's behavioral contract. I ask whether it can honor the base type's accepted inputs, guarantees, and failure behavior. If a ReadOnlyDocument inherits from EditableDocument but throws for Save, the hierarchy advertises a capability it cannot preserve. Shared fields such as Id and Name can be composed into a value or helper without claiming an is-a relationship.

Full answer below

Practice focus

Behavioral subtyping, substitutability, invariants, base contracts, code reuse, fragile hierarchies, and Liskov substitution.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Inheritance is appropriate when the derived type is behaviorally substitutable for the base type, not merely when two types share fields or methods. Callers using the base contract should continue to work correctly with every subtype.
I use inheritance only when the subtype can preserve the base type's behavioral contract. I ask whether it can honor the base type's accepted inputs, guarantees, and failure behavior. If a ReadOnlyDocument inherits from EditableDocument but throws for Save, the hierarchy advertises a capability it cannot preserve. Shared fields such as Id and Name can be composed into a value or helper without claiming an is-a relationship.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A useful base class has a stable purpose and a small set of deliberate extension points. Derived classes should not need to override most methods or inspect protected state to repair base behavior. I prefer shallow hierarchies and contract tests that run against each subtype. If behavior varies independently across several dimensions, strategies or decorators usually scale better than multiplying subclass combinations.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using inheritance because classes share properties.
Allowing a subtype to reject normal base operations.
Building deep hierarchies for every variation.
Using protected state as a substitute for a clear contract.

How do you decide whether inheritance is appropriate, and why is sharing some fields not enough to justify an is-a relationship?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement