Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is a discussion that I've occasionally tried to raise with colleagues. I usually find myself in a pretty isolated position, but anyway..

My viewpoint is, roughly:

1) DI, as described in the GoF book is a great pattern. You compose objects by passing other objects to its constructor as needed. These are the stored in final fields for the lifetime of the parent object. The pattern gives a lot of flexibility and handles a lot of use cases which it may otherwise be tempting to handle using the inferior concept of inheritance. It's simple, it's typesafe, it's easy to debug.

2) DI, as implemented by virtually any DI framework, is the Devil. Most DI frameworks is little more than a big dictionary mapping interface types (or magic strings) to implementation classes, along with some black-box magic to make it work (and bloat your stacktraces). It saves you the effort of calling constructors explicitly but any gains are lost as soon as you need to debug stuff. It shares a lot of traits with that other big dictionary where you can dump stuff for convenience: the global scope. It also has the same backdraws.

But anyway, this is a minority position so there is a large chance that I'm dead wrong and a small chance that history will prove me right.



Somehow I don't share your experience. What are the problem with DI and debugging? I had a lot WTF moments with automagical things, but not with pure DI.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: