I'll Be Backend
Search lessons / @illbebackend
Principles

Dependency Inversion Principle: Let the Policy Own the Interface

The Dependency Inversion Principle says business rules should not depend on technical details: the rule declares the interface it needs, in its own words, and the details implement it. These lessons take a web shop's receipt service that creates and calls a mail client itself, so switching receipts to text messages edits the receipt rule in three places, and refactor it until text messages arrive as one new class.

Pick your language

Dependency Inversion: let the policy own the interface in Java, step 2: Receipts go by textJava · ~6 minDependency Inversion Principle in JavaDependency Inversion: let the policy own the interface in C#, step 2: Receipts go by textC# · ~6 minDependency Inversion Principle in C#Dependency Inversion: let the policy own the interface in Python, step 2: Receipts go by textPython · ~6 minDependency Inversion Principle in PythonDependency Inversion: let the policy own the interface in PHP, step 2: Receipts go by textPHP · ~6 minDependency Inversion Principle in PHPDependency Inversion: let the policy own the interface in TypeScript, step 2: Receipts go by textTypeScript · ~6 minDependency Inversion Principle in TypeScript

When to use it

Use it when

A policy calls a detail that changes on its own schedule, like mail, text messages, storage or a payment vendor.

Skip it when

The class you call is stable, with no second version in sight, like String or List. An interface there only adds a name.

Spot it by

A business class that creates its own mail, database or HTTP client, or an interface whose methods copy a vendor API (to, subject, body) instead of what the caller needs.