Hi,
I’ve been experimenting with this technique lately with Spring, mainly web based systems, and I like it.
I wonder, has anyone used dependency injection for games? I’d be happy to read someones experience with this.
Note, I don’t really know how I would use this for games, but it might be well worth taking a look at.
IoC is made for application composition of more or less independ components or services. If you would write a modular game engine, IoC could be valueable. I would say it depends on the size and overall architecture of the software system you want to create, if using IoC can help you.
IoC is nonsense.
Quite successful nonsense. 
What backs your statement?
Framework-itis. Java developers tend to over-engineer everything. If I need A, B and C why in the name of God would I need to “inject” things so I can put the whole alphabet there? If you have any experience in projects then you realize things don’t change that often, and if they change it might cheaper/faster just to add a new letter there instead of abstracting the whole world. Spring is just a hack for enabling Java to do things that in other languages would be possible.
Athough I dislike Ruby and, above of all, the mystical-amazement-and-full-of-emotions way that Rubyists and their sect of zealots describe programming, I have to agree that Java may be painful sometimes not because of Java, but because of monstruosities like Spring that will force you to go through reams of XML in order to do the simplest things.
Conclusion: Spring is a non-solution for a non-problem.
For any kind of software with a plugin-like architecture, a good IoC container that supports distributed configuration (not Spring I believe) is absolutely invaluable. Perhaps you’re only writing small Tetris and Pong clones so you’ve never had the need for IoC, but I’m afraid that doesn’t make it nonsense in general.
I disagree. You can’t get rid of dependencies, you only move them from Java code to XML making everyone’s lives a hell.
Perhaps you’re just confusing the IoC concept with a particular container (Spring)? XML has nothing whatsoever to do with IoC. Spring uses it for configuration, but other containers such as Guice, picocontainer or tapestry-ioc don’t.
What’s all this IoC rubbish then?
Cas
Oh, I totally agree that XML can be the leading cause of headaches!
But, I wonder how you could practically use IoC in game programming. I’ve often wondered how I could design my games better.
Instead of hacking into the java code the level creation, creating instances of monsters, what kind of weapons those monsters have, what AI level, and the enviroment, you could do it in XML.
edit:
On second thought, this should probably belong to a external configuration file, not framework specific issues.
IoC is about three things:
If you don’t need/like this, then IoC is not for you.
And it might be personal taste, but I like spring 
Still clueless What’s it stand for? Is there an example of a real world problem it solves?
Cas
euh, no. you above definition is very concrete and bound to programming, spring and mostly limited to Depenency Injection.
Depenency Injection is a pattern. It’s about not making it the objects responsibily get it dependencies thefor creating/improving loosing coupling. principle of separating configuration from use.
http://en.wikipedia.org/wiki/Dependency_inversion_principle sums up DI quite nicely.
http://martinfowler.com/bliki/InversionOfControl.html
http://martinfowler.com/articles/injection.html#InversionOfControl
IoC / DI was coined and bound to programming but IoC really has a much wider scope, it’s about controll flow. It’s intesting in any system social, logic, etc.
Anyways IoC is relevant to games, as games are not stand alone and written in assembly anymore; they use frameworks. As far as DI goes it certainly has it’s uses. And programming against interfaces was always a good idea. Nothing changing? what you don’t profile apps? you only target one platform? You don’t need to improve the game balance? besides nothing forces you to externalise everything, I mean I like consistency but no one is forcing you.
Also since 2.0 spring allows you to do everything with annotations if you really wanted too. also I don’t understand the beef ppl have with xml, are you all still using notepath/vim to do your bisness? “I is is designed to be relatively human-legible” legible from Late Latin legibilis “that can be read”, note how that doesn’t include write persé you can always sausce that stuff with a fancy looking form or wizzard. Or perhaps ppl hate it with respect to quantity; ppl also introduced the concept of convention over configuration.
I found that the that whole part of of what spring introduces is far less intersting then using Aop to solve crosscutting concerns.
Ok, I should have been written: “IoC is useful in programming for at least three things:”
I don’t get the point here
Which pretty much distroys the “separationg configuration from use” principle (at least pragmatically, since you have to recompile your app to change it’s configuration)
IoC stands for Inversion of Control, and as you’d expect it does what it says on the tin. You invert who has control (normally over the source of some data or entity). The classic example of IoC is synchronous vs event driven programming, you give control to your components and they notify you via events, rather than keeping control and blocking on result. The software example is normally related to using a TextField (which fires an event when the input is read) rather than calling readLine().
DI, or Dependency Injection is a form a IoC that gives control of your depedencies over to some external entity (the injector). The injector framework (there are quire alot now) is responsible for configuring your depdencies based on some meta data, which up to recently has mostly been a stack of XML but now seems to be moving towards annotations (at least in Java). A poor but apt example may be the implementation of the data driver you’re using. Your code, as always, is only dependent on the data driver interface and holds an uninitialised reference to the driver it’s going to use. The XML defined which driver implementation you want to use, and the injection framework is responsible at startup for creating the instance of the driver and linking up the reference to it.
There are several places in games development where injection could be useful above and beyond the normal software engineering use cases, resource injection for instance.
I’m not sure what parallel you’re drawing with AOP though. Dependency injection is really an augmentation of existing OOM, AOP is a different way of looking at it. They don’t solve the same problem afaik.
I’m also of the opinion that DI is total junk tbh, it’s popular like many things in the enterprise world - because it ticks a technology box for architects everywhere. It’s technical merit seems pretty limited to me. The concept IoC is perfectly sound though, just the DI frameworks in existence seem to be a bit pointless.
Long live AOP!
was mostly in response to the “why should I do all that crap, I almost never changes” Was trying to point out that there are other uses that reimplementing your bisnesslogic or rewriting the UI or any other layer. there are more ‘fine grained’/suble cases. Tis hard to explain and I can’t think of a simple example of the top of my head.
“…if you wanted too”
Also haven’t looked into it but I hope XML overrides inline.
The following error or errors occurred while posting this message:
Warning - while you were typing a new reply has been posted. You may wish to review your post.
Oi kevin “bring’s clairity” glass to the rescue.
[quote]I’m not sure what parallel you’re drawing with AOP though.
[/quote]
Spring has populalised a number of techniques, DI beeing one of them AOP an other. Along the lines of “I’m working with spring now… …can this be used in games” I was trying to point out that if you want to use/bring in a ‘Spring’ technique; then I would shift focus from DI to AOP.
Ah, in that case I’m totally with you. I’m only recently getting into AOP, but it’s changing my views on lots of things - it’s a real eye opener
Kev
Sceptics say, AOP will introduce more trouble than vantages, since it not only hides controll flow (like DI) but large chunks of actual work from the programmer… but there are naysayers with everything
I keep meaning to look into AOP. What are you using, AspectJ? Whats the situation on IDE intergration/tools?
I’m using the JBoss AOP, and mostly I’m not having engineer any, just understand how they’ve used it in the AS. So, I’m just ploughing through their AOP configuration and understanding what the hell is going on
I think thats sort of right tbh, both AOP and DI seperate bits of the implementation in unexpected ways, making code harder to understand and maintain unless you really get the techs involved. However, the difference for me is that DI does this in a facet where you have to understand it no matter what you’re doing and the pay off isn’t very good, i.e. it allows you to configure your coupling elsewhere - something we’ve all be used to with factory methods for years. In the case of AOP unless you’re interested in the advice being applied you should be able to ignore it - and the pay off is beautiful, applying cross cutting changes globally and being able to tweak at a moments notice without having to have made provision before hand - thats wonderful
Thought, my experience of AOP is much less than IoC/DI so I may yet to be experience the extreme downsides
Kev