Scenario: Refactoring a God Class Using SOLID, Patterns, and Strangler

Q: Scenario: Refactoring a God Class Using SOLID, Patterns, and Strangler

**Don't rewrite — refactor incrementally behind tests.** Step 1: **characterization tests** pin current behavior so changes are safe. Step 2: **extract collaborators by responsibility** (pricing, inventory, payment, notifications, tax) into focused classes via **Extract Class** — SRP from SOLID. Step 3: apply **targeted patterns** where they earn their keep: **Strategy** for pricing/tax (policy varies by region, product, channel), **Chain of Responsibility** for order validation pipeline, **State** for order lifecycle (sealed types + pattern matching), **Adapter** for external payment/shipping gateways, **Decorator** or AOP for cross-cutting (logging, metrics, retry), **Command** for auditable operations (CQRS-lite). Step 4: **Strangler Fig** — route new functionality through the new abstractions; shrink the god class call-by-call until it's a thin facade or deleted. Step 5: **repository pattern** to unify SQL access; **DI** to replace hidden dependencies. Critical discipline: **small PRs with green tests at every step**, measure success (coverage, cyclomatic complexity, test latency, bug rate), and resist over-pattern-izing — not every method needs a pattern. Common failures: Big Bang rewrite, pattern-over-engineering, skipping tests, mixing refactor with feature work.

Intermediate·5 min read·

GoogleStripeShopifyThoughtworks

Fast recall

Quick revision

Core answer

Don't rewrite — refactor incrementally behind tests. Step 1: characterization tests pin current behavior so changes are safe. Step 2: extract collaborators by responsibility (pricing, inventory, payment, notifications, tax) into focused classes via Extract Class — SRP from SOLID. Step 3: apply targeted patterns where they earn their keep: Strategy for pricing/tax (policy varies by region, product, channel), Chain of Responsibility for order validation pipeline, State for order lifecycle (sealed types + pattern matching), Adapter for external payment/shipping gateways, Decorator or AOP for cross-cutting (logging, metrics, retry), Command for auditable operations (CQRS-lite). Step 4: Strangler Fig — route new functionality through the new abstractions; shrink the god class call-by-call until it's a thin facade or deleted. Step 5: repository pattern to unify SQL access; DI to replace hidden dependencies. Critical discipline: small PRs with green tests at every step, measure success (coverage, cyclomatic complexity, test latency, bug rate), and resist over-pattern-izing — not every method needs a pattern. Common failures: Big Bang rewrite, pattern-over-engineering, skipping tests, mixing refactor with feature work.

Interview Answer5 min

Don't rewrite. Refactor incrementally behind tests. Here's my sequence.

Step 1: Stabilize

Characterization tests: run the god class with representative inputs, capture outputs, pin current behavior
Introduce minimal seams — interfaces for external calls so I can mock
Target 80%+ coverage on what I'll refactor; higher on critical paths like payment
Mutation testing to check test quality
Optional: shadow traffic comparing old and new in prod

Step 2: Extract by responsibility (SRP)

PricingEngine: rules, discounts, promotions; Money value type (BigDecimal + currency)
TaxCalculator: per jurisdiction
InventoryService: reserve, release, confirm; wraps repository
PaymentService: authorize, capture, refund; idempotency keys explicit
ShippingService: rates, labels, tracking
NotificationService: listens to events, not called directly
ValidationPipeline: ordered chain of validators
OrderFacade: thin orchestration, publishes domain events
Rich domain: invariants on entities (order.cancel), not service methods

Step 3: Apply targeted patterns

Strategy: pricing and tax — one implementation per channel/jurisdiction; DI for registry
Chain of Responsibility: validation pipeline
State + sealed types: order lifecycle with pattern-matched transitions
Adapter: payment and shipping gateways behind ports
Decorator/AOP: cross-cutting — logging, metrics, retry, circuit breaker
Command + handler: auditable operations, natural audit log
Observer/events: decouple notifications from commerce flow
Repository: hides SQL, returns domain objects
Avoid over-patterning — if one implementation with no variation, don't add Strategy

Step 4: Strangler Fig

New callers use new abstractions
Old callers keep using god class unchanged
Migrate old callers sprint by sprint
God class shrinks; eventually delete
Feature flag per flow — enable for 1% traffic first

Step 5: Small PR discipline

Each PR one extraction or one migration
Tests green; no behavior change
Under 30 min review
No long refactor branches
Don't mix refactor with features — separate PRs

Sequence

1
Characterization tests for pricing
2
PricingEngine interface + extracted impl
3
Migrate one caller to PricingEngine
4
Repeat until all callers migrated
5
Delete god-class pricing method
6
Repeat for inventory, payment, tax, notifications

Measuring progress

LOC of OrderService per week (drops)
Cyclomatic complexity of remaining methods
Coverage on new services (≥ 90%)
Build/CI time
Bug rate on order flow
Lead time for new payment methods or tax jurisdictions

Trade-offs

Big Bang vs incremental: always incremental unless fundamental architecture mismatch
Refactor vs rewrite: prefer refactor; rewrite only when architecture cannot meet future needs
Patterns too few vs too many: pattern when variation is real, not speculative
Coverage vs velocity: 80% line / 90% on critical paths
Ports everywhere vs pragmatic: ports for volatile/untrusted, not for stable
Anemic vs rich domain: invariants live on entities, orchestration in services

Common mistakes

Big Bang rewrite
Refactor without tests
Over-patternization
Long refactor branches
Mixing refactor with features
Mass renames in structural PRs
Skipping measurement
Heroics without knowledge spread
Deleting quirks without understanding — might be load-bearing
Golden plating

Senior behaviors

Stabilize first
Small independent PRs
Patterns where they earn keep
Measure progress
Communicate to team, manager, product
Pair with teammates — knowledge spreads
Revert cleanly, no ego
Celebrate deletions — net-negative-LOC days are good days

Interview emphasis

Tests first
Name SOLID as I apply
Name patterns when they fit; reject when they don't
Strangler + feature flags + characterization tests
Measurement and success criteria
Admit trade-offs — no single right answer

Bottom line

Replace a 3,000-line god class with focused services, targeted patterns, ports for volatile dependencies, and a rich domain model — via dozens of small, safe PRs
Tests and measurement make the risk acceptable
Patterns are tools, not goals

Interview-ready guide

Interview answer