The Runtime Theory
mediumdesign-pattern-reference#strategy#dependency-inversion

Isolate Shipping Rules Behind a Strategy

Refactor a checkout calculation so rate rules can vary without spreading carrier-specific branches through the order workflow.

The Runtime Theory Team1 min read
Solve it

Solving happens on the judge — come back and mark it done

Sample cases

inCheckout constructed with a flat-rate policy

outReturns the configured rate without importing carrier API details

inCheckout constructed with a carrier adapter that times out

outMaps the failure to a domain result and follows an explicit fallback policy

Start with a checkout method that contains if carrier == ... branches. Define the smallest policy contract that the order flow needs, move each calculation behind an implementation, and inject the choice at the application boundary.

Add tests with a deterministic fake policy and an integration test for a carrier adapter. Include the timeout case: an abstraction should not hide the fact that one implementation makes a remote call and can fail.

In your write-up, name the expected change that justifies the interface. If only one stable behavior exists, explain why the extra layer is still useful or remove it. The linked reference shows the Strategy shape; this exercise asks you to decide whether that shape fits the pressure in your own code.

One dispatch a week

The trace behind each problem, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.

Not started

Sign in to save your learning progress.

Sign in to save