Instruction 3

In the last demo, you learned about the Interface Segregation principle. Now, it’s time to learn about the final principle, Dependency Inversion, which is defined like this:

Depend upon abstractions, not concretions.

Different parts of your code should not depend on concrete classes — they don’t need that knowledge. Instead, rely on protocols to connect parts of your app.

Following this principle ensures that the different parts of your system are abstracted from each other, reducing coupling.

Using protocols to design functionality is just like designing the blueprints of a car before beginning production. Once you’ve defined all the different parts and how they connect on paper, you can build everything in parallel to save time. You can even implement upgrades by swapping one part with an enhanced version.

You might wonder why base classes aren’t enough. Base classes are meant to include functionality, whereas protocols aren’t. Protocols specify what the object should do — not how to do it.

When a module relies on another module’s abstraction, it can’t create an instance of that module directly because doing so would require knowledge of the concrete type. Therefore, modules with abstract dependencies expect to receive the instances they’ll use for their operations.

To understand this better, you’ll apply the Dependency Inversion principle to the example from the first demo.