This week's book giveaway is in the Functional programming forum.
We're giving away four copies of Functional Design and Architecture and have Alexander Granin on-line!
See this thread for details.
Win a copy of Functional Design and Architecture this week in the Functional programming forum!
  • 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
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Disadvantages of IOC

 
Ranch Hand
Posts: 113
Hibernate Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I got this question in one of the Interview.
What are the Disadvantages of using IOC.

I answered that beans created using spring IOC are singletons and it is a disadvantage when we require non singleton beans in our application. Is it correct ?
 
Bartender
Posts: 4121
IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No - because even though singleton beans are the default - you can set the scope to override this.

One drawback of using IoC frameworks is that it's harder to navigate the code. Entry points into the program aren't as obvious. Things are usually called through interfaces, and methods are invoked inside of abstract super classes inside the framework, making it hard to figure out exactly what implementation is being called in a specific spot, or when exactly something is called.

Of course, the *benefits* of using IoC usually outweigh this.
 
ranger
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nathan Pruett wrote:No - because even though singleton beans are the default - you can set the scope to override this.

One drawback of using IoC frameworks is that it's harder to navigate the code. Entry points into the program aren't as obvious. Things are usually called through interfaces, and methods are invoked inside of abstract super classes inside the framework, making it hard to figure out exactly what implementation is being called in a specific spot, or when exactly something is called.

Of course, the *benefits* of using IoC usually outweigh this.



Some people, myself included would put all your drawbacks and call them benefits. I actually find it so much easier to navigate code using Spring and DI. ;)

Mark
 
Mark Spritzler
ranger
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OH, but I would accept those answers if I asked the question of the post. But then in the interview I would explain why I also think of them as huge benefits.

Mark
 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I never knew there would be disadvantages to IoC/DI... I would've said "What disadvantages?"

If one is having trouble understanding wiring configuration then it's probably not done right. Then again I can see some developers are getting carried away by putting all wirings through Spring. Also, using Annocations everywhere can be bad practices too. Maybe even go crazy with new Spring Expressions. Also, many Spring purist see any "new" or "extend" as an axis of evil. Do I really have to wire a bean that's "ArrayList" to assign to any class that has a "List"...seriously? They would create interface for every possible objects when they clearly know there will be one and only implementations. Then they say "This is good design by promoting interfaces and you can add new or change implementations later". It really does make good buzz words to the managers that it's good. Of course, 5 years later there is NO new implementation as we already knew.. Yes, it doesn't hurt to add 9999 interfaces but having 9999 java file that doesn't contain any benefits isn't common sense. I'm not saying I don't make interfaces for a single class. For example, if I want to utilize Mock frameworks then I will do so. Damn it... I'm getting off topic. I guess Spring DI can be crazy if one person "pre-optimizes the architecture" which makes it complex over some issues you'll never encounter.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic