#design-principles

7 post(s)

SOLID in Practice:Apply the Five Without the Ceremony

Walk one order/payment notification service through all five SOLID principles end to end — the seams that matter, the ones that do not, and when to stop applying the checklist.

SOLID

Dependency Inversion:Depend on Abstractions, Not on `new`

Apply Dependency Inversion in Java: move Stripe and SMTP construction out of OrderProcessor, inject abstractions, and see how Spring DI is one wiring option — not the principle itself.

SOLID

Interface Segregation:Stop Forcing Clients to Depend on What They Ignore

Apply Interface Segregation in Java: break a fat PaymentOperations interface into client-shaped seams so charge, refund, and report clients stop stubbing unused methods.

SOLID

Liskov Substitution:Subtypes That Don't Surprise Callers

Spot Liskov Substitution violations in Java inheritance — UnsupportedOperationException, tightened preconditions, null surprises — and replace dishonest subtypes with honest types.

SOLID

Open-Closed:Add Behavior Without Rewriting the Core

Apply the Open-Closed Principle in Java: replace growing if/switch payment forests with extension seams so new providers are added, not edited into the core.

SOLID

Single Responsibility:One Reason to Change, Not One Method

What the Single Responsibility Principle actually means — one audience, one reason to change — with a Java OrderProcessor god class split into cohesive pieces.

SOLID

SOLID Roadmap:Five Principles Without the Textbook

What SOLID means in practice, a glossary of the five principles, when they become cargo-cult, and a map of this series — with a shared order/payment domain for later posts.