Dependency Inversion Principle (DIP)

Analogy 1: Swappable Phone Chargers

Imagine if every phone had a unique charging port, and you needed a different charger for each device. That would be inconvenient. Now think of how USB chargers work—they create a standard, and any phone with a USB port can use the same charger, regardless of the brand. The charger and phone depend on the same abstraction (the USB standard) rather than on each other’s specifics.

DIP promotes this kind of flexibility, where classes rely on abstract concepts (interfaces) instead of concrete details, making your code adaptable to different implementations.

Analogy 2: Electric Outlet and Appliances

Think of the electrical outlets in your home. These outlets are designed to provide power to any appliance—whether it's a toaster, a TV, or a computer. The outlet doesn’t need to be modified for each appliance; it simply provides electricity through a standard plug interface.

In this case, the electrical outlet is the high-level module, and the appliances are the low-level modules. The outlet doesn't need to know the specifics of the appliances (what they do or how they work), just that they follow the standard plug interface.

In DIP terms: The outlet (high-level) doesn't depend on specific appliances (low-level), and both rely on the abstraction of a standard plug.

Analogy 3: Universal Electrical Adapters

Imagine you are traveling to a foreign country where the wall sockets are different. Instead of buying new appliances, you get a universal adapter that works with any socket, regardless of the type. The adapter creates an abstraction, allowing your devices to work anywhere without being tightly coupled to the specifics of one country’s electrical system.

In software, DIP works similarly. Instead of tightly coupling your high-level code to specific implementations (like only supporting one kind of socket), you depend on abstractions (like the adapter), which makes the system more flexible and adaptable to changes.

Definition:

High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces or abstract classes).

DIP encourages the decoupling of software modules by ensuring that both high-level and low-level modules depend on abstractions, making your code more flexible and easier to maintain.