SOLID Principles

ISP — the "I" in SOLID — says no caller should be forced to depend on operations it never uses. Instead of one large interface with many unrelated methods, define several small ones, each matching what a particular caller actually needs.

If type S is a subtype of type T, code written against T must keep working correctly when handed an S. A subtype must honour the promises its supertype made — not just match method names.

You should be able to add new behavior to a module by adding new code (a new class or plug-in), without editing and re-testing the existing, already-working code.

SRP says a class or module should do one job, so only one kind of change forces you to edit it. If both a reporting change and a tax-rule change hit the same class, it has two responsibilities.

It violates the Single Responsibility Principle: the class changes for three unrelated reasons (report wording, file storage, email delivery). Split it into a formatter, a storage writer, and a sender, and let a small coordinator call all three.

Control flow stays the same: OrderService still calls the email code at runtime. The source dependency flips: OrderService declares a Notifier interface, EmailSender implements it, so the low-level code now references the high-level module's abstraction rather than the reverse.

DIP is a design goal about which way source dependencies point. Inversion of Control is a broader style where an outside caller or framework drives your code. Dependency Injection is a concrete technique: hand an object its collaborators from outside instead of it creating them.

Look for implementations with empty bodies, return null, or "not supported" exceptions; callers that use one or two methods of a large type; and mocks/fakes full of unused stubs. Fix by extracting one small interface per role and letting classes implement several.

A subtype may not demand more than the base (preconditions can only be weakened), must promise at least as much as the base (postconditions can only be strengthened), and must keep every rule the base always held true (invariants preserved).

A mutable Rectangle lets you set width and height independently. A Square must keep them equal, so its setters change both. Code that sets width 5, height 4 and expects area 20 gets 16 — the subclass broke a rule the base promised.

Create one interface with the four behaviors, and one implementation per customer type holding that type's four branches. The billing code looks up the right implementation and calls it, so a new type is a new class, not four edits.

Look for a class that many unrelated features depend on, has a vague name like Manager or Helper, holds lots of loosely related fields, needs many dependencies to construct in a test, and shows up in almost every commit.

Signals: an override that throws 'not supported', callers doing type checks before calling, or a subclass that rejects inputs the parent accepts. Fix by narrowing the interface, using composition instead of inheritance, or splitting the hierarchy so each type only promises what it can deliver.

It violates the Open/Closed Principle: adding a variant forces editing existing code. Replace the repeated conditionals with polymorphism - one interface per payment method with fee, validate and charge behaviour - so a new method means adding a class, not editing three.

You can't be closed against every change, only the ones you predict. Write simple direct code first; add the abstraction when a second real variant shows up or history says that axis changes. One-implementation interfaces built "just in case" are cost with no payoff.

Add characterization tests first, extract each responsibility into its own class, keep the original class as a thin wrapper that delegates so callers keep compiling, migrate callers gradually, then shrink or delete the wrapper. Each new piece is now testable alone.

When the abstraction guesses wrong or is never needed: interfaces with one implementation forever, factories wrapping factories, layers you must step through to read simple logic. Add the abstraction when a second real variant appears, not before.

Narrow interfaces make test doubles tiny — you fake one or two methods instead of twenty — so tests are shorter and state the collaboration clearly. They also shrink the blast radius of a change: fewer files reference the type, so fewer things recompile, re-mock, or redeploy.

A Decorator wraps an existing object behind the same interface and adds behavior around it (caching, retry, logging) without touching the wrapped class. A plug-in extension point lets the core discover and call implementations it has never heard of, registered at startup or install time.

The consumer owns it. The high-level module declares the interface it needs, in its own package, in terms of its own vocabulary; the implementing module depends on that package. If the interface lives with the implementation, the policy still imports infrastructure and nothing is inverted.

No. Mirroring every class with a same-shaped interface adds indirection without decoupling: the interface changes whenever the class does, so the client is still tied to the implementation. Real inversion means the abstraction is client-shaped and crosses a meaningful boundary.

The caller should define it. An interface written from the caller's needs (a "role interface") stays small and stable. An interface that just mirrors an existing class's full public surface (a "header interface") adds a file but removes no coupling.

ISP is about not exposing callers to operations they don't use; LSP is about subtypes being usable anywhere the supertype is. A too-wide interface forces implementers to stub or throw on operations they can't support — and a caller that invokes one then breaks, which is an LSP failure.

Yes — clients told the interface supports add now crash at runtime. The implementation delivers less than the interface promised. The fix is to split the interface so read-only types never advertise mutation.

Overrides may return a more specific type (covariant returns) because promising more is safe, and could in theory accept a more general parameter type (contravariant parameters) because demanding less is safe. Most languages enforce only the return-type rule.

You can only be closed against changes you predicted. Using interfaces makes adding a new implementation cheap but adding a new method to the interface expensive — every implementation must change. A big switch statement has the opposite trade-off.

Cohesion means the parts of a module belong together; coupling means how much modules depend on each other. SRP is a rule for picking boundaries that keeps cohesion high. Splitting into one-method classes raises coupling without adding cohesion.

They are not independent. A fat interface (ISP violation) forces implementations to stub methods they cannot support (LSP violation), so callers add type checks, which means adding a type forces editing callers (OCP violation) - and callers now depend on concrete types (DIP violation).

SRP is harmful when you split by guesswork. Extra classes add indirection, wiring and reading cost. If one team owns all the behavior and changes always arrive together, leaving it as one module is the cheaper, clearer design.