Dependency Injection: useful when you have an ever changing set of objects, plug-ins, etc; a burden when you have a strict, well defined set of objects that isn't going to change any time soon.
Dependency Injection: useful when you have an ever changing set of objects, plug-ins, etc; a burden when you have a strict, well defined set of objects that isn't going to change any time soon.
Thoughts?
Thoughts?
You always need to write unit tests, so you always want to isolate your objects, so you always have a changing set of objects that any given class will use.
ReplyDeleteIt's never a "burden".
That depends you see... you don't necessarily need mock objects and that kind of stuff. That's the point I am trying to make; it's like putting too many clothes on, you may well end up thirsty unnecessarily :-)
ReplyDeleteWhen don't you need mock objects?
ReplyDeleteI'd say the only time is when the dependency is on an RTL class, and even then you need to be careful and ensure that your RTL object isn't creating unwanted side-effects.
Absolute rules are unmitigatingly bad, and yes, that applies recursively.
ReplyDeleteok a couple of examples. Example 1: years ago I was developing a kiosk application. Thanks to the millionth change of spec :-) I had to add banners at the 4 edges of the screen. I created 1 model class and then used 4 objects of that single class. Had I done it with DI, I would a) spent 3 times the time I spent on it and b) not gained anything in terms of testability or functionality simply because THAT was never going to change. EVER.
ReplyDeleteEric Grange Did I state an absolute rule? No, it seems to me I gave a rule with exceptions. Do you need to read more carefully?
ReplyDeleteAndrea --
ReplyDeleteWhy would it have taken three times longer to to it with, say, constructor injection?
Testability is always enhanced by isolation. Creating hard-coded dependencies doesn't allow for isolation.
which hard coded dependencies? It was totally self-contained and used an event to serve the following file name :-) there were also several frames handling different kinds of content(images,video,etc.).
ReplyDeleteand the data was being read by another bit of the application which would serve as a loose controller
ReplyDeleteNick because 4 years ago I'd have had to write LOADS of infrastructure code. A
ReplyDeleteIf you call MyClass.Create in a constructor, then you have a hard-coded dependency.
ReplyDeleteIf you don't, then you aren't creating a dependency (generally speaking).
If I remember correctly, I was creating the objects in the OnCreate. I always try and keep a separation of remits(I prefer this to concerns) as much as possible.
ReplyDeleteI try to tie as little code as possible to event handlers.
ReplyDeleteYeah, if you put "business" code things get wild pretty soon :-) It's different though when the code meaning business is well tuck away. It's always about striking a balance; DI and stuff like that work fantastically when you haven't got a clue of who will be there when, but that isn't always the case :-)
ReplyDeleteLoosely coupling objects is always a great idea. It makes the world of sense 2 years down the line when the code needs to be maintained.
ReplyDelete