Exercises — SOLID — Dependency Inversion Principle

Line A violates DIP. ReportService is a high-level module (policy: "produce a report"). PdfWriter is a low-level module (mechanical detail: bytes to a PDF). The word new PdfWriter() welds the policy directly to a concrete detail.

The dependency arrow points: ReportService → PdfWriter (concrete). DIP wants both to point at an abstraction instead. Line B is fine in spirit — calling write is what we want; the sin is who created the object and what type the field is.

• High-level = BillingPolicy — it decides what should happen (charge the customer, apply discounts). It is the valuable, slowly-changing business asset.
• Low-level = StripeApiClient — it is a swappable mechanism (how bytes reach Stripe's servers). It could be replaced by PaypalApiClient tomorrow.

Rule of thumb: the module whose deletion would change what the product does is high-level; the module whose deletion only changes how a step is carried out is low-level.

• UserService → Repository (policy depends on the abstraction).
• SqlRepository → Repository (detail depends on — implements — the abstraction).
• Repository depends on nothing (an interface is a pure contract, no implementation).

Notice both real classes point at the interface. That "both arrows converging on the abstraction" shape is DIP.

Step 1 — introduce an abstraction the policy owns.

interface WeatherSource { double fetchTemp(); }

Why: gives WeatherApp a stable contract to depend on instead of a concrete class.

Step 2 — make the detail implement it (invert its arrow up).

class OpenWeatherClient implements WeatherSource { ... }

Why: the concrete's dependency arrow now points up at the contract.

Step 3 — inject the concrete; never new it inside.

class WeatherApp {
    private final WeatherSource src;
    WeatherApp(WeatherSource s){ this.src = s; }
    double todayTemp(){ return src.fetchTemp(); }
}

Why: removes the last source-code dependency on OpenWeatherClient. WeatherApp.java now compiles knowing only WeatherSource.

• DIP version: 0 existing files. You create one new file MockWeatherSource implements WeatherSource and inject it in the test. WeatherApp is untouched.
• Non-DIP version: 1 existing file (WeatherApp itself), because the concrete OpenWeatherClient is hard-wired inside — you'd have to change the field and constructor.

The count dropping from 1 → 0 on the core policy file is the concrete payoff of inversion: change becomes additive (add a leaf) instead of invasive (edit the core).

The interface PaymentGateway lives in core.billing (with the policy that owns it).

Then infra.stripe → core.billing (the detail package depends on the policy package). This is the truly inverted direction. Had you put the interface in infra.stripe, then core.billing → infra.stripe, and your valuable policy would again depend on an infrastructure package — the very thing DIP forbids.

Here $C_a=8$ (8 arrows in), $C_e=2$ (2 arrows out). $I=\frac{C_e}{C_a+C_e}=\frac{2}{8+2}=\frac{2}{10}=0.2$ $I=0.2$ is close to $0$, so M is fairly stable — many depend on it, it depends on little. Good: stable modules are exactly where you want other code to point.

Before: $I=\frac{3}{5+3}=\frac{3}{8}=0.375$. After: $I=\frac{1}{5+1}=\frac{1}{6}\approx 0.167$.

Instability dropped ($0.375\to 0.167$): OrderService became more stable because it now depends on far fewer things. DIP literally moved a high-value module toward $I=0$ — toward being a rock others can safely build on.

// package core.checkout  (policy owns the contract)
interface PaymentGateway { Receipt charge(Money m); }

class CheckoutService {
    private final PaymentGateway gateway;
    CheckoutService(PaymentGateway g){ this.gateway = g; }   // injected
    Receipt buy(Cart c){ return gateway.charge(c.total()); }
}

// package infra.stripe   (detail points UP into core)
class StripeGateway implements PaymentGateway { ... }

// NEXT MONTH — new file only, zero core edits:
// package infra.paypal
class PaypalGateway implements PaymentGateway { ... }

Arrows: CheckoutService → PaymentGateway, StripeGateway → PaymentGateway, PaypalGateway → PaymentGateway. Package arrows: infra.stripe → core.checkout, infra.paypal → core.checkout. Adding PayPal = 1 new file + 1 injection wiring line; 0 edits to CheckoutService.

Use a factory (see Factory Pattern) at the composition edge:

class GatewayFactory {
    PaymentGateway create(String cfg){
        if (cfg.equals("stripe")) return new StripeGateway();
        return new PaypalGateway();
    }
}
// wiring (main / IoC container):
PaymentGateway g = new GatewayFactory().create(config);
CheckoutService svc = new CheckoutService(g);   // injected abstraction

Concrete gateway names visible inside CheckoutService: 0. All new StripeGateway() / new PaypalGateway() live in the factory at the outer edge. CheckoutService still sees only PaymentGateway. This is DIP (goal) delivered by Dependency Injection + Factory Pattern (techniques). An IoC container would automate the same wiring.

• OCP: Yes. Adding PaypalGateway without editing CheckoutService means the module is open for extension, closed for modification — DIP's inverted arrow is precisely what enables OCP.
• Strategy: PaymentGateway with interchangeable StripeGateway/PaypalGateway is the Strategy pattern — swappable algorithms behind one interface. DIP explains why the arrow inverts; Strategy is a shape that realizes it at runtime.
• Ports & Adapters: PaymentGateway is a port owned by the core; StripeGateway is an adapter in the infrastructure ring. Hexagonal architecture is DIP applied systematically to every external boundary.

class ReportService {
    private final PdfWriter writer;                  // concrete TYPE
    ReportService(PdfWriter w){ this.writer = w; }   // injected!
}

This injects writer (classic DI — no new inside), yet the declared parameter/field type is the concrete PdfWriter. So ReportService.java still has a compile-time dependency on a low-level detail. DI is satisfied; DIP is not. Fix: change the type to an interface DocumentWriter. This proves DIP (goal: depend on abstractions) ≠ DI (technique: pass objects in).

Use a service locator / factory lookup returning the abstraction:

class ReportService {
    private final DocumentWriter writer =
        Registry.get(DocumentWriter.class);   // returns an abstraction
    void run(){ writer.write("hi"); }
}

ReportService depends only on DocumentWriter (the abstraction) and on Registry (a lookup utility) — never on a concrete writer. So DIP holds even though we didn't inject through the constructor. (Trade-off: the service-locator hides dependencies and is generally considered inferior to DI for testability — but it is DIP-compliant. Goal met by a different technique.)

Let $E_{\text{DIP}}(n)$ = core edits with DIP, $E_{\text{no}}(n)$ = core edits without DIP.

With DIP: you edit the core once to introduce the abstraction, then every provider is a new leaf file + wiring (outside the core). So $E_{\text{DIP}}(n)=1(\text{constant, independent of }n).$ Without DIP: each provider is hard-wired into the core, so each addition edits the core once: $E_{\text{no}}(n)=n.$ At $n=5$: $E_{\text{DIP}}(5)=1$ and $E_{\text{no}}(5)=5$. The saving is $5-1=4$ core edits avoided, and the ratio grows without bound as $n$ increases ($E_{\text{no}}/E_{\text{DIP}}=n$). This is why DIP turns "$O(n)$ invasive changes" into "$O(1)$ core change + additive leaves."