• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

DI and IOC

 
Ranch Hand
Posts: 338
Scala Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

I am working on spring framework for a long time.

I am still trying to understand a better picture related to DI and IOC.

DI: It is about injecting the dependancies in the dependant objects via some external means.
IOC : It is about the the Flow of control, it is about the direction, Instead of application taking the responsiblity, it is the framework which takes the responsibilty.

So I understand, that Spring is based on these two concepts.


But I wish to understand about, Struts 1, Struts2, JSF or even servlets and JSPs or any other MVC or COMPONENT-Container based architectures are IOC as It is the container(Framework) which manages the lifecycle and not the application?

If there are any dependancies which needs to be injected, like HttpServletRequest, HttpServletResponse in case of HttpServlet. These Object are created by the container and injected into the Servlet during lifecycle. Hence it is DI?

Similarly in case of Threads, Thread Lifecycle is managed by JVM(Framework), Hence it is IOC.

Android Activity Lifecycle, Managed by DVM , It is IOC.

EJB Lifecycle managed by EJB Container or Application Server, It is IOC?

Even event based GUI Frameworks like AWT, Swing are IOC as it is Lifecycle is managed by Events. and If The Event Objects are injected by the event driven thread, Hence it is DI?

Frameworks like RMI, JNDI following Service Locator Pattern are IOC? and since There is a reference to the Remote Interface to be injected, RMI is DI?

Event Driven Frameworks and Design Patterns like

State-Observer Pattern,
Factory Pattern,
Abstract Factory,
Service Locator Pattern,
Application Callbacks,
Method Template Patterns
Container Component Archictures
Servlets, Filters or anything which has mabaged Lifecycles

are DI and IOC?

Can any one explain me what is DI but not IOC and what is IOC but not DI?

I had a disscussion on a blog www.howtodoinjava.com.

Can you please verify that discussion

The link is as follows:

http://howtodoinjava.com/2013/03/19/inversion-of-control-ioc-and-dependency-injection-di-patterns-in-spring-framework-and-related-interview-questions/

Please read the comments and discussion on the above link.

Please help me clear this,


Regards,
-Pankaj.











 
Marshal
Posts: 5794
368
IntelliJ IDE Python TypeScript Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your summary of DI is roughly correct. Which also summarises IoC because DI and IoC are the same thing.
 
Sheriff
Posts: 17734
302
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Cooke wrote:Your summary of DI is roughly correct. Which also summarises IoC because DI and IoC are the same thing.


No, DI and IoC are not quite the same things although they almost always go hand-in-hand. This http://martinfowler.com/bliki/InversionOfControl.html and this http://martinfowler.com/articles/injection.html help clarify the difference.
 
Junilu Lacar
Sheriff
Posts: 17734
302
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pankaj Shet wrote:
If there are any dependancies which needs to be injected, like HttpServletRequest, HttpServletResponse in case of HttpServlet. These Object are created by the container and injected into the Servlet during lifecycle. Hence it is DI?


I don't know if I would consider this as DI. I don't think that everything that involves a parameter being passed is necessarily DI. I guess I would consider it a more clear-cut case of DI if there was a choice between creating the reference to the collaborator or using a service locator versus having the reference to the collaborator provided from the outside. In other words, it's DI when you have a choice between actively obtaining a reference to the collaborator vs passively getting it.

In the case of the servlet response and request objects, there's really no reasonable choice other than to have the web container pass these in. If anything, this is more related to IoC because the class that receives the servlet request and response is not in control of the flow but rather just waiting there, ready to react to being "called into service" by the web container when a request comes in. You have no control over when this code is executed, the web container (the framework) does.

The other aspect of DI is timing. I consider it DI when the collaborator reference is provided when you're either creating or configuring the object. In Fowler's article, he lists three types of injection: constructor, setter, and interface injection. The only thing you're doing when a reference to a collaborator is injected is saving that reference for later use. Actually doing something with that reference comes when IoC happens, when whatever is controlling the flow of execution activates the code that has been injected with a reference to its collaborator(s) to accomplish something.
 
Junilu Lacar
Sheriff
Posts: 17734
302
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


State-Observer Pattern,
Factory Pattern,
Abstract Factory,
Service Locator Pattern,
Application Callbacks,
Method Template Patterns
Container Component Archictures
Servlets, Filters or anything which has mabaged Lifecycles

are DI and IOC?


I think you're giving DI and IoC a much broader coverage than what they actually have. Neither DI nor IoC is broad enough to encompass everything in this list. Nothing about the Factory Pattern or the State-Observer Pattern has any direct relationship to DI or IoC. The ideas behind these things you have listed are orthogonal to DI and IoC and any correlation you may find between them are purely incidental, IMO. Edit: Service Locator Pattern is actually the opposite of the idea behind DI.

To give you a clear-cut example: in Java 8, we now have lambda expressions. Are these DI or IoC? The question does not even make any sense because lambda expressions have nothing to do with DI or IoC. You can certainly use DI to provide lambda expressions to classes so that they are not creating the lambda expressions themselves. Do you see the difference?
 
Pankaj Shet
Ranch Hand
Posts: 338
Scala Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for reply Juniper.

But I cannot still believe that what I said is not DI.

See. Lets take an example of Servlets.

public class MyServlet implements HttpServlet{

public void doGet(HttpServletRequest request, HttpServletRequest request){
//Servlet code.
}

public void doPost(HttpServletRequest request, HttpServletRequest request){
//Servlet code.
}

}


Read this link:

http://martinfowler.com/articles/dipInTheWild.html


If you check this link,

Under "You mean Dependency Inversion, Right?" section,

you will find the explaination of all three

DI, IOC and DIP

DI: "Dependency Injection is about how one object knows about another, dependent object."

IOC: "Inversion of control is about who initiates messages. Does your code call into a framework, or does it plug something into a framework, and then the framework calls back? This is also referred to as Hollywood's Law; don't call me, I'll call you."

DIP: "Dependence Inversion is about the shape of the object upon which the code depends"


After all three Topics,

There is a summary which says:
"DI is about how one object acquires a dependency. When a dependency is provided externally, then the system is using DI.
IoC is about who initiates the call. If your code initiates a call, it is not IoC, if the container/system/library calls back into code that you provided it, is it IoC.
DIP, on the other hand, is about the level of the abstraction in the messages sent from your code to the thing it is calling "

The Last Line of the entire topic again summarizes all three:

"DI is about wiring, IoC is about direction, and DIP is about shape."

The example which he gives

Imagine a software player that needs to send the roll() message to a software pair of dice. How does the player object get a reference to the dice object? Imagine the game tells the player to takeATurn(ice) and gives the player the dice. The game telling a player to take a turn and passing the dice is an example of method level dependency injection. Imagine a system where the Player class expresses a need for Dice instead and it gets auto-wired by some kind of so-called IoC container like Spring.

How can this be related to our servlet.?

or any of the Frameworks and the Patterns I mentioned above.?

Regards,
-Pankaj.












 
Pankaj Shet
Ranch Hand
Posts: 338
Scala Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Juniper I guess you are correct:

I think The following class demonstrates DI

public class MyServlet implements HttpServlet
{
HttpServletRequest request;
HttpServletResponse response;

public MyServlet(HttpServletRequest request, HttpServletResponse response){ //Constructor Injection
this.request = request;
this.response = response;
}
//or

//GETTERS

public void setHttpServletRequest(HttpServletRequest request){ //Setter Injection
this.request=request;
}

public void setHttpServletResponse(HttpServletResponse response){ //Setter Injection
this.response=response;
}

public void doGet(){
request.xxx(); //Using the Injected Parameters.
response.xxX();
}

public void doPost(){
request.xxx(); //Using the Injected Parameters.
response.xxX();
}

public void doGet(HttpServletRequest request, HttpServletResponse response){ // No Injection normal call
//Servlet code.
}

public void doPost(HttpServletRequest request, HttpServletResponse response){ // No Injection normal call
//Servlet code.
}

}


Regards,
-Pankaj.

 
Pankaj Shet
Ranch Hand
Posts: 338
Scala Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Struts 2 ObjectFactory Implements DI in something similar fashion
 
Junilu Lacar
Sheriff
Posts: 17734
302
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pankaj Shet wrote:Juniper I guess you are correct:


You either need to watch your autocorrect function or read my name properly. It's Junilu, not Juniper, thank you.
 
Junilu Lacar
Sheriff
Posts: 17734
302
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your example of MyServlet is a poor one. It's not a good practice to have instance variables in a Servlet because you get concurrency issues. Also, Servlets don't work that way. Requests and Response objects are created for each client request received by the web container.

As the article says, DI is about wiring dependencies rather than actively acquiring them via a service locator or instantiation in the dependent object. The relationship is long term and last longer than the one invocation of a method. Sure, you may be dependent on parameters passed in to a method but this doesn't constitute DI. If anything, the design principle that I would relate to using method parameters is The Law of Demeter.

As I said before, not everything is DI or IoC -- these concepts have a narrower scope that what you are thinking.

And again, my name is Junilu, not Juniper
 
Pankaj Shet
Ranch Hand
Posts: 338
Scala Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok Thanks a lot Junilu, for your reply.


 
Or we might never have existed at all. Freaky. So we should cherish everything. Even this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic