Disadvantages of IOC

[Tanu Gulati]

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 ?

[Nathan Pruett]

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.

[Mark Spritzler]

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]

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

[Kevin Cho]

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.