Announcement Announcement Module
Collapse
No announcement yet.
spring IOC DOUBT UNDERSTOOD BUT HAS SOME DOUBTS Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • spring IOC DOUBT UNDERSTOOD BUT HAS SOME DOUBTS

    What is Spring IOC?

    As far as my Undestanding,(Please Correct if iam wrong)

    Say there r 2 classes Class X, Class Y.
    Now the requirement is Class X needs to access methods of Class Y.

    So normally we create an object of Class Y in Class X and then access the methods of Class Y from Class X.(Object of Class Y is created at runtime that is only when new operator is called on Class Y).

    Here Class X depends on Class Y by creating an Object of Class Y in Class X. That is Class X creates an Object of Class Y.

    When we go for IOC (Inversion of Control), which means Control is getting Inverted. (Here Control means Creation of Object.)
    (Inverted/Inversion means instead of Class X creating an Object of Class Y somebody who implements IOC creates an Object of Class Y)

    When we apply the above requirement (requirement is Class X needs to access methods of Class Y.) to the Spring IOC, Spring Container (which implements IOC) creates an Object of Class Y and gives the reference of object of Class Y to Class X
    at runtime(Here we r not calling any new operator on Class Y in Class X).

    So when we use Spring IOC, Class X is not creating an Object of Class Y. Spring Container creates an object of Class Y and give the reference(that is inject the reference of Object Class Y to Class X by Constructor or Setter Injection) of the Object Class Y to Class X.

    Here I have few doubts:

    1) what is the use(difference between)of Spring IOC creating an Object Of Class Y for Class X instead of Class X creating an Object of Class Y that is normal approach of creating object? Any advantages? If so what are those advantages?

    2) And is there any difference between creating an Object in normal approach as compared to creating an Object by Spring IOC at runtime.
    My friends say that in case of Spring IOC an object of Class Y is created only when there is any method invocation of Class Y from Class X. Is it true? But there is a property called lazy-init which when set to true creates an Object when Spring Container is created that is at same time both are created. In this scenario my friends concept is wrong.

    So can anybody explain me the above doubts?

  • #2
    Please any one explain my doubt

    Please any one explain

    Comment


    • #3
      Originally posted by kiran291 View Post
      ...

      Here I have few doubts:

      1) what is the use(difference between)of Spring IOC creating an Object Of Class Y for Class X instead of Class X creating an Object of Class Y that is normal approach of creating object? Any advantages? If so what are those advantages?

      2) And is there any difference between creating an Object in normal approach as compared to creating an Object by Spring IOC at runtime.
      My friends say that in case of Spring IOC an object of Class Y is created only when there is any method invocation of Class Y from Class X. Is it true? But there is a property called lazy-init which when set to true creates an Object when Spring Container is created that is at same time both are created. In this scenario my friends concept is wrong.

      So can anybody explain me the above doubts?
      I'd recommend you to read the following article from Martin Fowler - Inversion of Control Containers and the Dependency Injection pattern.

      About your concern:
      1. It's much more flexible to inject ClassY to the ClassX because we can inject whatever reference we need then. For example, we can inject mocks during unit testing or remote service proxy etc. Many of the spring functionality uses that extensively, e.g. spring AOP is built via injecting aop-aware proxies as a dependencies and spring transactions are built on top of spring aop;
      2. That is not completely true. There are many nuances with lazy beans initialization. You can read the following about that:

      Comment


      • #4
        So what u mean is that we could inject any class into another class at runtime which

        So what u mean is that we could inject any class into another class at runtime which avoids recompiling of java classes by configuring classes and their collaborators in an XML file

        Originally posted by denis.zhdanov View Post
        I'd recommend you to read the following article from Martin Fowler - Inversion of Control Containers and the Dependency Injection pattern.

        About your concern:
        1. It's much more flexible to inject ClassY to the ClassX because we can inject whatever reference we need then. For example, we can inject mocks during unit testing or remote service proxy etc. Many of the spring functionality uses that extensively, e.g. spring AOP is built via injecting aop-aware proxies as a dependencies and spring transactions are built on top of spring aop;
        2. That is not completely true. There are many nuances with lazy beans initialization. You can read the following about that:

        Comment


        • #5
          hi denis.zhdanov thanks for ur reply So what u mean is that we

          hi denis.zhdanov

          thanks for ur reply

          So what u mean is that we could inject any class into another class at runtime which avoids recompiling of java classes by configuring classes(their properties and references) and their collaborators in an XML file .

          Comment


          • #6
            Originally posted by kiran291 View Post
            hi denis.zhdanov

            thanks for ur reply

            So what u mean is that we could inject any class into another class at runtime which avoids recompiling of java classes by configuring classes(their properties and references) and their collaborators in an XML file .
            That is one of the benefits. The trick is that we can inject any object or proxy to the target object, e.g. proxy to the remote service.

            Comment

            Working...
            X