Tag: oop

Interpreter:Represent a Grammar and Evaluate It

Model a tiny promo DSL as AND/OR of percent-off and sku-in-category expressions that evaluate(Order), and skip it when a few ifs or a real parser would be honest.

Design Patterns

Visitor:Add Operations Without Changing the Elements

Add CSV export and tax walks to a stable Sku / Category tree with accept(Visitor) so each new report is a class, not another method on every catalog type.

Design Patterns

Prototype:Copy an Object Instead of Reconstructing It

Clone a configured DiscountPolicy, ChargeRequest, or gateway test double in Java instead of rebuilding constructor arguments — and skip clone() when new is cheaper or the copy shares mutable guts.

Design Patterns

Memento:Snapshot State Without Breaking Encapsulation

Undo a checkout draft in Java by letting Order take an opaque snapshot — no public fields, no JSON dump, and no serializing OrderProcessor.

Design Patterns

Mediator:Keep Colleagues from Talking to Each Other

Stop DiscountPolicy, PaymentGateway, fraud, inventory, and the notifier from importing each other by letting CheckoutMediator own the checkout conversation.

Design Patterns

Flyweight:Share What Does Not Change

Share immutable catalog SKU metadata across cart LineItems so a Black Friday order does not clone name, tax class, and image URL on every row.

Design Patterns

Bridge:Split Abstraction from Implementation

Stop the Email×SendGrid / SMS×Twilio subclass grid by letting OrderNotifier hold a MessageSender so channels and vendors vary independently.

Design Patterns

Iterator:Walk a Collection Without Exposing Its Guts

Stop walking Order line items with get(i) on a leaked ArrayList so a switch from list to a SKU tree does not rewrite OrderProcessor.

Design Patterns

Abstract Factory:Families of Objects Without Naming the Concrete Types

Build Stripe-region and Razorpay-region checkout families in Java so gateway, webhook parser, and money type vary together without OrderProcessor naming the concretes.

Design Patterns

Chain of Responsibility:Pass a Request Until Someone Handles It

Replace a hard-coded fraud-inventory-payment-notify sequence with a Handler chain in Java so a new checkout step is a class you splice in, not a next-type you edit.

Design Patterns

State:Change Behavior When Internal State Changes

Replace a growing DRAFT / PAID / REFUNDED / VOID switch in process, refund, and void with OrderStatus objects that own legal transitions, so OrderProcessor stops being the state machine.

Design Patterns

Composite:Treat Trees of Objects as One

Replace nested loops over Outdoor / Hiking / SKUs with a CatalogNode tree so a category and a single product both answer subtotal(), and OrderProcessor still charges one payable.

Design Patterns

Proxy:Stand In for an Object You Cannot Touch Directly

Put a PaymentGateway proxy in front of a slow SDK so OrderProcessor still calls charge, while lazy init, an auth check, and a last-result cache decide whether the real gateway runs.

Design Patterns

Command:Turn a Request into an Object

Turn charge, refund, and capture into Java objects you can queue, retry, undo, or audit — without wrapping a one-shot process() in ceremony.

Design Patterns

Facade:One Simple Front for a Messy Subsystem

Hide checkout’s discount, payment, fraud, and tax conversation behind one CheckoutFacade.place(Order) so controllers stop assembling the subsystem.

Design Patterns

Template Method:Freeze the Skeleton, Vary the Steps

Freeze a shared Java payment sequence so capture, refund, and void keep one skeleton and only the provider step (and hooks) vary.

Design Patterns

Singleton:One Instance, Used Carefully

Keep a process-wide resource as an enum singleton only when you can name why there must be one, and inject Clock, config, and gateways into OrderProcessor instead of AppContext.getInstance().

Design Patterns

Builder:Assemble Complex Objects Step by Step

Replace a telescoping ChargeRequest constructor with a Java builder so required checkout fields stay required, optional ones stay optional, and the product can still be a record.

Design Patterns

Adapter:Make Incompatible Types Talk

Wrap a vendor client whose methods do not match PaymentGateway so OrderProcessor keeps calling charge(Order, BigDecimal) and never learns PayPal’s shape.

Design Patterns

Decorator:Add Behavior Without Subclassing the Core

Replace AuditedRetryingCachedGateway subclasses with PaymentGateway wrappers you compose at the edge — logging, retry, cache — without a new type per combination.

Design Patterns

Observer:Notify Dependents When Something Changes

Stop editing OrderProcessor for every new notification channel by publishing a payment event and letting EmailNotifier and AuditLog subscribe.

Design Patterns

Factory Method:Let Subclasses Decide Which Object to Build

Move construction of DiscountPolicy and PaymentGateway behind a polymorphic creator so six controllers stop naming PercentOff and StripeGateway.

Design Patterns

Strategy Pattern:Swap Algorithms Without Editing Callers

Replace a growing discount if/else with a Strategy in Java so each new promotion is a class you add, not a branch you edit into OrderProcessor.

Design Patterns

Design Patterns Roadmap:Pick the Right Pattern for the Pain You Have

A map of creational, structural, and behavioral patterns — what pain each one solves, when to skip it, and links to every post in this series.

SOLID

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.