Geek Answers Handbook

What should be built through the IOC container?

How do you determine which classes should be built through the IOC container and which should not. I worked on projects with both extremes, and it seems that interfaces should only be used when classes specify a specific technology, such as logging or data access?

Where do people draw a line between the two?

+6
dependency-injection inversion-of-control
source share
2 answers

I do not draw a single line - the more the merrier.

What happens is that the more you can separate your API in small units, the closer you are to the principle of shared responsibility , because everything that is hidden behind the interface will tend to do only one thing and do it well.

By introducing interfaces into the implementation that implement new interfaces that are introduced into other types, etc., you get a very flexible structure where you can change the implementation details at almost any level, and each of them is quite simple in itself.

With a good DI container and some reasonable conventions, a DI container will automatically take care of most of the wiring for you, so the configuration should not be extreme.

+3
source share

The classes created by the DI container (provided that one is used) must be those that implement the Split Interface , and this is necessary for being selected at runtime depending on the runtime.

Then you may ask: which classes should implement the shared interface, and which should not? There are two main reasons for creating a new separate interface:

  • You need to break the dependency between the two parts of the system (just do not do this simply because you can).
  • You will have several independent implementations (keep in mind that it is usually easy to introduce a separate interface later through refactoring, so “something” should be avoided).

For reference see http://martinfowler.com/articles/injection.html#SeparatingConfigurationFromUse

+1
source share

More articles:


All Articles