When NOT to apply the Dependency Inversion Principle?

In layman's words:

Applying the DIP is both easy and fun. Not getting the design right at the first attempt is not enough reason giving up on the DIP altogether.

• Usually IDEs help you do that kind of refactoring, some even allow you to extract the interface out of an already implemented class
• It's almost impossible to get the design right the first time
• The normal workflow involves changing and rethinking the interfaces in the first stages of developement
• As development evolves it matures and you will have less reasons to modify the interfaces
• In an advanced stage the interfaces (the design) will be mature and will hardly change
• From that moment on, you begin to reap the benefits, since your app is open to scale up.

In the other hand, programming with interfaces and OOD can bring the joy back to the sometimes stale craft of programming.

Some people say it adds complexity but I think the opossite is true. Even for small projects. It makes testing/mocking easier. It makes your code to have fewer if any case statements or nested ifs. It reduces cyclomatic complexity and makes you think in fresh ways. It makes programming more alike to real-world design and manufacturing.

Use dependency inversion where it makes sense.

One extreme counterexample is the "string" class included in many languages. It represents a primitive concept, essentially an array of characters. Assuming you could change this core class, it makes no sense to use DI here because you will never need to swap out the internal state with something else.

If you have a group of objects used internally in a module that are not exposed to other modules or reused anywhere, it is probably not worth the effort to use DI.

There are two places where DI should automatically be used in my opinion:

1. In modules designed for extension. If the entire purpose of a module is to extend it and change behavior, it makes perfect sense to bake DI in from the start.

2. In modules that you are refactoring for the purpose of code reuse. Perhaps you coded a class to do something, then realize later that with a refactor you can leverage that code elsewhere and there is a need to do so. That is a great candidate for DI and other extensibility changes.

The keys here are use it where it is needed because it will introduce extra complexity, and make sure you measure that need either through technical requirements (point one) or quantitative code review (point two).

DI is a great tool, but just like any* tool, it can be overused or misused.

_{* Exception to the above rule: a reciprocating saw is the perfect tool for any job. If it does not fix your problem, it will remove it. Permanently.}

The short answer is "almost never", but there are, in fact, a few places where the DIP doesn't make sense:

1. Factories or builders, whose job it is to create objects. These are essentially the "leaf nodes" in a system that fully embraces IoC. At some point, something has to actually create your objects, and can't depend on anything else to do that. In many languages, an IoC container can do it for you, but sometimes you need to do it the old-fashioned way.

2. Implementations of data structures and algorithms. Generally, in these cases the salient characteristics that you're optimizing for (such as running time and asymptotic complexity) depend upon specific data types being used. If you're implementing a hash table, you really need to know that you're working with an array for storage, not a linked list, and only the table itself knows how to properly allocate the arrays. You also don't want to pass in a mutable array and have the caller break your hash table by fiddling with its contents.

3. Domain model classes. These implement your business logic, and (most of the time) it only makes sense to have one implementation, because (most of the time) you're only developing the software for one business. Although some domain model classes might be constructed using other domain model classes, this is generally going to be on a case-by-case basis. Since domain model objects don't include any functionality that can be usefully mocked, there's no testability or maintainability benefit to the DIP.

4. Any objects which are provided as an external API and need to create other objects, whose implementation details you don't wish to expose publicly. This falls under the general category of "library design is different from application design". A library or framework may make liberal use of DI internally, but will eventually have to do some actual work, otherwise it's not a very useful library. Let's say you're developing a networking library; you really do not want the consumer to be able to provide its own implementation of a socket. You might internally use an abstraction of a socket, but the API you expose to callers is going to create its own sockets.

5. Unit tests, and test doubles. Fakes and stubs are supposed to do one thing and do it simply. If you have a fake that's complex enough to worry about whether or not to do dependency injection, then it's probably too complex (perhaps because it's implementing an interface that's also far too complex).

There might be more; these are the ones I see on a somewhat frequent basis.

It seems to me that the original question is missing part of the point of the DIP.

The reason I am skeptical is because we are paying some price for following this principle. Say, I need to implement feature Z. After analysis, I conclude that feature Z consists of functionality A, B and C. I create a fascade class Z, that, through interfaces, uses classes A, B and C. I begin coding the implementation and at some point I realize that task Z actually consists of functionality A, B and D. Now I need to scrap the C interface, the C class prototype and write separate D interface and class. Without interfaces, only the class would wave needed to be replaced.

To truly take advantage of the DIP, you would create class Z first, and have it call the functionality of classes A, B and C (which are not yet developed). This gives you the API for classes A, B and C. Then you go and create classes A, B and C and fill in the details. You effectively should be creating the abstractions you need as you're creating class Z, based entirely on what class Z needs. You can even write tests around class Z before classes A, B or C are even written.

Remember that the DIP says that "High-level modules should not depend on low-level modules. Both should depend on abstractions."

Once you have worked out what class Z needs and the way in which it wants to get what it needs, you can then fill in the details. Sure, sometimes changes will need to be made to class Z, but 99% of the time this won't be the case.

There will never be a class D because you worked out that Z needs A, B and C before they were written. A change in requirements is a different story altogether.

Some signs you may be applying DIP at too micro of a level, where it's not providing value:

• you have a C/CImpl or IC/C pair, with only a single implementation of that interface
• the signatures in your interface and implementation match one-to-one (violating DRY principle)
• you frequently change C and CImpl at the same time.
• C is internal to your project and not shared outside your project as a library.
• you are frustrated by F3 in Eclipse/F12 in Visual Studio taking you to the interface instead of the actual class

If this is what you're seeing, you might be better off just having Z call C directly and skip the interface.

Also, I don't think of method decoration by a dependency injection / dynamic proxy framework (Spring, Java EE) the same way as true SOLID DIP - this is more like an implementation detail of how method decoration works in that tech stack. The Java EE community considers it an improvement that you don't need Foo/FooImpl pairs like you used to (reference). By contrast, Python supports function decoration as a first-class language feature.

See also this blog post.

I will go out on a limb and say that I have never found a valid use case for dependency inversion. I believe this term is mostly tossed around by theorists, because you will notice that in practice things are often not as easy as just "switching out an implementation for another".

Why is that? Because there are in my experience only limited cases where changing the API won't be accompanied by changes to the API's constructor, method or the way the API is used. You will then have to dig into the abstraction layers as well and change how stuff is routed, which is exactly what DI promises to avoid. My two cents are that you're in general better of changing just one class instead of having to nurture the abstraction layer as well.

As a mostly C++ programmer I will also say that introducing virtual calls for no reason will also have performance implications. Not huge ones and such can probably be devirtualized by a modern compiler, but it's still one more thing to keep in mind.

On another note: Do not mistake dependency inversion for dependency injection. Those are not the same thing. Dependency injection is a very powerful pattern that has a lot of real world use cases.

If you always invert your dependencies, then all your dependencies are upside down. Which means that if you started with messy code with a knot of dependencies, that's what you still (really) have, just inverted. Which is where you get the problem that every change to an implementation needs to change its interface too.

The point of dependency inversion is you selectively invert the dependencies that are making things tangles. The ones that should go from A to B to C still do so, it the ones that were going from C to A that now go from A to C.

The result should be a dependency graph that is free of cycles - a DAG. There are various tools that will check this property, and draw the graph.

For a fuller explanation, see this article:

The essence of applying the Dependency Inversion Principle correctly is this:

Split the code/service/… you depend on into an interface and implementation. The interface restructures the dependency in the jargon of the code using it, the implementation implements it in terms of its underlying techniques.

The implementation remains where it is. But the interface has a different function now (and uses a different jargon/language), describing something the using code can do. Move it to that package. By not placing the interface and implementation in the same package, the (direction of the) dependency is inverted from user→implementation to implementation→user.