How to Fix a Broken Object-Oriented Design (Step by Step)

Knowing that a design is “wrong” is not the same skill as making it right. Many candidates can say “this is a God Class” and then freeze — because remediation needs a sequence, not a vibe.

This walkthrough gives you a repeatable repair process you can use in interviews and in legacy reviews. For a catalog of smells to recognize first, see common LLD design mistakes.

01The Repair Loop

1. Stabilize the contract — what must still work after the change?
2. Name the violation — SRP, LSP, coupling, wrong relationship.
3. Find the seam — where can you cut without rewriting the world?
4. Extract or invert — new type, interface, or pattern.
5. Re-wire — update relationships; delete dead weight.
6. Validate — does the original violation still exist? Did you invent a new one?

02Worked Example: Breaking Up a God Service

Before: RideService books rides, calculates fare, charges cards, sends SMS, and writes analytics.

// Smell: RideService does everything
RideService
  + requestRide()
  + estimateFare()
  + chargeCustomer()
  + notifyDriver()
  + trackEvent()

Step 1 — List change reasons

• Fare rules change → pricing.
• Payment provider changes → payments.
• SMS vs push → notifications.
• Analytics vendor changes → telemetry.
• Booking flow changes → ride orchestration.

Step 2 — Extract by reason-to-change

RideService (orchestration only)
  - FareCalculator
  - PaymentGateway (interface)
  - Notifier (interface)
  - AnalyticsClient (interface)

FareCalculator
StripePaymentGateway implements PaymentGateway
SmsNotifier implements Notifier

Step 3 — Validate

• Booking flow still goes through RideService.
• Adding WhatsApp notifications does not edit fare or payment code.
• No new circular dependencies between collaborators.

03Choosing the Right Move

Patterns are tools for a diagnosed problem — not stickers. If you cannot name the violation, do not reach for Decorator.

04Interview Tips While You Fix

• Narrate the violation before editing: “I’m extracting pricing because fare rules change independently.”
• Keep a temporary facade if callers must stay stable.
• Prefer many small extractions over one dramatic rewrite mid-interview.
• Ask whether functional equivalence is required — in refactor prompts it usually is.

Critique practice belongs in Debug Lab. When you need to restructure on a canvas and validate against a clean target, use Debug & Fix.

05Avoid These Remediation Traps

• Rename-only fixes — OrderManagerGod renamed to three still-coupled types.
• Interface theater — one implementation forever, no call sites depending on the abstraction.
• Behavior drift — “fixing” SRP by dropping a required use case.
• Big-bang rewrite — deleting the entry API mid-interview with no facade.

06Practice Exercise

ReportGenerator loads DB rows, formats CSV and PDF, emails stakeholders, and caches results. Sketch a repaired design in ten minutes. Then compare: did you separate loading, formatting, delivery, and caching?

07Key Takeaways

• Fixing needs a loop: stabilize → diagnose → seam → extract → validate.
• Split types by reason-to-change, not by “feels big.”
• Use patterns to complete a remediation, not to decorate a resume.
• Preserve behavior while changing structure.

Practice active remediation in Debug & Fix — detect, restructure, and check your design against the expected clean model.