6. Dependency Inversion Principle (DIP)

Question 1

What does the DIP state?

Answer 1

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules—both should depend on abstractions. It also goes on to say that abstractions should not depend on details, but rather details should depend on abstractions.

Question 2

What are the two kinds of dependencies in C#?

Answer 2

1. Compile-time dependencies — references required to compile.
2. Run-time dependencies — references required to run.

Question 3

What kind of dependencies does the DIP mostly have to do with?

Answer 3

Compile-time dependencies.

Question 4

What direction should your project references point if the DIP is followed?

Answer 4

Away from your low-level infrastructure code and towards high-level business abstractions.

Question 5

What is “high-level” in the context of the DIP?

Answer 5

Constructs in our code that

1. tend to be more abstract,
2. relate more to the problem domain and our business rules,
3. are generally more process-oriented than detail-oriented,
4. and are further away from input/output (eg. forms, buttons, files, databases).

Question 6

What is “low-level” in the context of the DIP?

Answer 6

Constructs in our code that

1. are closer to I/O (where is the input coming from?),
2. are commonly referred to as “plumbing code,”
3. interact with specific external systems and hardware.

Question 7

How does seperation of concerns relate to the DIP?

Answer 7

The Dependency Inversion Principle is all about applying separation of concerns — high-level concerns like your domain model or business rules should be kept separate from your low-level concerns like plumbing code.

Question 8

What are abstractions in C#?

Answer 8

Abstractions in C# refer primarily to interfaces and abstract base classes. Essentially, the types you cannot instantiate.

Question 9

What construct is generally prefered for abstractions in C# and why?

Answer 9

Interfaces over abstract base classes because interfaces don’t require object inheritance and are a bit more flexible.

Question 10

What do abstractions define?

Answer 10

A contract — a way of working with the type without actually specifying how that work is going to get done.

Question 11

What are “details” in the context of the DIP?

Answer 11

Concretions, essentially.

Question 12

What does the DIP state?

Answer 12

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules—both should depend on abstractions. It also goes on to say that abstractions should not depend on details, but rather details should depend on abstractions.

Question 13

What does the DIP state?

Answer 13

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules—both should depend on abstractions. It also goes on to say that abstractions should not depend on details, but rather details should depend on abstractions.

Question 14

What can be said about abstractions vs details in the context of the DIP?

Answer 14

Abstractions shouldn’t be coupled to details, meaning that they shouldn’t know about the specifics of how they are implemented.

Question 15

What is the difference between abstractions and details?

Answer 15

Abstractions describe the “what” (eg. send a message, store a Customer record), whereas details specify the “how” (eg. send an SMTP email over port 25, serialize Customer to JSON and store it in a text file).

Question 16

What are some examples of low-level dependencies in an application?

Answer 16

1. Database
2. File System
3. Email
4. Web APIs
5. Configuration details
6. System clock

Question 17

What are hidden direct dependencies, in what form are they usually manifested, what do they cause and why?

Answer 17

The direct use of low-level concerns from the high-level concerns. Usually, these will take the form of static calls or the new keyword being used to directly create instances of low-level types. These direct dependencies cause pain because they introduce tight-coupling, are more difficult to isolate and unit-test, and promotes duplication.

Question 18

What is new?

Answer 18

new is glue. :) Using new to create dependencies glues your code to that dependency — it will tightly couple one class to another.

new isn’t bad, but just bear in mind the coupling it creates — do you need to specify the implementation or could you work with an abstraction instead?

Question 19

What does the Explicit Dependencies Principle state?

Answer 19

Classes should explicitly require their dependencies through their constructor and shouldn’t surprise clients with dependencies. Think of the dependencies as ingredients in a cooking recipe — always list them upfront.

Question 20

How does Dependency Injection relate to the DIP?

Answer 20

They go hand in hand. Following the DIP will mean that the client code injects the class’s dependencies.

Question 21

How can dependencies be injected for a class?

Answer 21

Ideally, as constructor arguments. However, they can also be injected through properties or method arguments.

Question 22

What are the advantages of using a constructor for injecting dependencies?

Answer 22

1. Follows the Explicit Dependencies Principle
2. Classes are never in an uninitialised state
3. Can leverage an Inversion of Control container to construct types and their dependencies

Question 23

What is the DIP key to?

Answer 23

The Dependency Inversion Principle is the key to reducing coupling — especially coupling to specific implementation details.

Question 24

What is the first step in implementing DIP?

Answer 24

Identifying an interface using ISP and modify the code to depend on the interface rather than the concrete implementation.

Question 25

What are the key takeaways of this module?

Answer 25

1. Most classes should depend on abstractions, not implementation details.
2. Abstractions shouldn’t leak details.
3. Classes should be upfront and explicit about their dependencies.
4. Clients should inject dependencies when they create other classes.
5. Structure your solutions to leverage dependency inversion.