An interface has file-system, cloud-storage, and read-only implementations. What must remain true for callers to substitute them safely?

Liskov substitution and behavioral contracts

Explains substitutability through inputs, outputs, side effects, and failure behavior rather than inheritance syntax alone.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Each implementation must honor the interface's documented behavior: accepted inputs, returned results, failure cases, and important side effects. A subtype should not require stronger preconditions or provide weaker guarantees than the abstraction promises. If read-only storage cannot support WriteAsync, throwing NotSupportedException may show that the interface combines capabilities that should be modeled separately.

Full answer below

Practice focus

Behavioral contracts, preconditions, postconditions, exceptions, side effects, capability modeling, and misleading inheritance.

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
Polymorphism is safe only when implementations preserve the contract callers rely on. Matching method signatures is not enough if one implementation rejects normal inputs or changes the meaning of success.
Each implementation must honor the interface's documented behavior: accepted inputs, returned results, failure cases, and important side effects. A subtype should not require stronger preconditions or provide weaker guarantees than the abstraction promises. If read-only storage cannot support WriteAsync, throwing NotSupportedException may show that the interface combines capabilities that should be modeled separately.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would split contracts such as IBlobReader and IBlobWriter when consumers need different capabilities. The cloud implementation may have eventual consistency or transient failures that the file implementation does not. Those semantics must either fit the shared contract or be exposed deliberately. Tests should be written against the contract and run for every implementation, covering missing objects, overwrite rules, cancellation, and error translation rather than only happy-path return values.

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

Treating matching signatures as a complete contract.
Using NotSupportedException for a normal advertised operation.
Hiding materially different consistency guarantees.
Testing implementations separately without shared contract tests.

An interface has file-system, cloud-storage, and read-only implementations. What must remain true for callers to substitute them safely?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement