convention-solid-lsp

Liskov Substitution Principle (LSP) requires that subtypes remain fully substitutable for their base types without altering the correctness or behavior of consuming code. Violations occur when derived classes loosen or strengthen contracts, causing contract drift and runtime errors in inheritance-heavy codebases.

To refactor a base processor for LSP compliance, enforce contract preservation across the inheritance hierarchy to maintain substitutability. Use explicit interfaces, wrappers, and stable return contracts to ensure the derived class does not require changes in the consuming client code.

You need to apply LSP-compliant refactoring when extending inheritance-heavy codebases, designing APIs, or modifying data loaders and processors. It is required when you must satisfy explicit contract maintenance and ensure extensions do not cause behavioral contract drift in consuming code.

The best way to decouple extensions without strengthening base contracts is by using explicit interfaces and wrappers. This approach preserves stable return types and maintains the original behavioral contracts, ensuring safe extension without violating LSP substitutability.

Substituting a subclass causes runtime errors because it violates LSP by loosening or strengthening the base class behavioral contracts, creating contract drift. The consuming code expects the original contract, so the altered subclass behavior breaks the application.

Yes, you can use interfaces and wrappers to decouple extensions and preserve return contracts during inheritance refactoring. This technique maintains explicit contract preservation across the hierarchy, ensuring subtypes remain safely substitutable for their base types.