What is wrong in my way of explainning DI and IoC?

Question

Yesterday during an interview I was asked what DI and IoC in spring were. My reply was:

when a class(A) extends abstract class(B) or implements interface(B) or create a object of class(B) of any class in it, then A is said said to be dependent on B. Injecting this dependency, i.e. injecting the object in costructor or in setter method is called DI and in this process control over creating object goes to the "outside world" like XML configuration, this inversion of control is IoC. DI is not necessary IOC. We can still have DI when there is no IOC.

The interviewer didn't agree with me - where was I wrong?

One more thing-

As we used Super class reference variable or coding through interface in constructor or setter method parameter.Is this any way related with DI/IOC or this is only to achieve loose coupling?

Answer 1

IoC (Inversion of Control) : inverts the flow of control as compared to traditional control flow i.e. We should not create object and control flow instead framework create Objects, wire them together and manage their lifecycle and uses DI to Manage Components i.e. creation of objects.

There are several basic techniques to implement inversion of control.

• Using a factory pattern
• Using a service locator pattern
• Using Dependency Injection(DI), for example
  • Constructor injection
  • Parameter injection
  • Setter injection
  • Interface injection
• Using a contextualized lookup
• Using template method design pattern
• Using strategy design pattern

Source

Answer 2

Your answer makes sens and I do share the same opinion with a slight variation.

IoC concept was initially heard during the procedural programming era. Therefore from a historical context IoC talked about inversion of the ownership of control-flow i.e. who owns the responsibility to invoke the functions in the desired order - whether it's the functions themselves or should you invert it to some external entity.

However once the OOP emerged, people began to talk about IoC in OOP context where applications are concerned with object creation and managing the relationships between the objects as well, apart from the control-flow. Such applications wanted to invert the ownership of object-creation (rather than control-flow) and required a container which is responsible for object creation, object life-cycle & inject dependencies of the application objects thereby eliminating application objects from creating other concrete object.

In that sense DI is not the same as IoC, since it's not about control-flow, however it's a kind of Io*, i.e. Inversion of ownership of object-creation.

I have discussed further on this topic here.

Answer 3

First statement***"when a class(A) extends abstract class(B) or implements interface(B)"***

This is inheritance , which can not be injected as dependency via Spring

Second Statement "create a object of class(B) of any class in it, then A is said said to be dependent on B"

sounds good

" Injecting this dependency, i.e. injecting the object in costructor or in setter method is called DI "

Not a clear statement to explain dependency injection. Here the meaning of injection needs to be explained. that is Management of dependencies is handled by spring container , It is who control their lifecycle and thus delegate/inject to the classes who ask for them(via spring config file )

"his process control over creating object goes to the "outside world" like XML configuration"

Here control neither goes to the outside world nor to the xml configuration file but to the spring container. And spring container uses this configuration file to do its work.

"this inversion of control is IoC. DI is not necessary IOC. We can still have DI when there is no IOC."

Though no issues with it but seems incomplete. Here IOC needs to be explained. Trying to explain it via image