Is the dependency inversion principle that I have to create an interface for each module?

Question

If I want my code to comply with SOLID principles, in particular the dependency inversion principle, does this mean that I need to create an interface (abstraction) for each module, even if it has only one implementation?

In my opinion, and according to these reports:

http://josdejong.com/blog/2015/01/06/code-reuse/

http://blog.ploeh.dk/2010/12/02/Interfacesarenotabstractions/

creating an “abstraction” for each module is a messy code and violates the YAGNI principle.

My rule: do not use dependency injection or create an interface for a module if it has no more than one implementation (the second implementation can be a mock class for unit testing in the case of database / server / file modules).

Can someone clarify this for me? Does SOLID mean that I have to enter each module and abstract it? If so, isn't that just a mess, we just won’t use most of the time?

Answer 1

The dependency inversion principle states:

High-level modules should not be dependent on low-level modules. Both should depend on abstractions.

In other words, every module that it depends on (so everything except the entry point modules in your application) should be abstracted. Otherwise, the high-level module must directly depend on the low-level module, causing a DIP violation.

DIP, - . .

, , , , :

.

, , , , . ( ), , , .

, :

• ICommandHandler <TCommand> , ( ).
• IQueryHandler < TQuery, TResult > , ( , -, -) .
• IValidator <T> ,
• ISecurityValidator <T> , , .
• IAuthorizationFilter <T> , .
• IEventHandler <T> , , .

. , .

, , , . 90% 98% ( , , ).

DI (, , .NET), , , . , , . , .