Hi. Hopefully I’m going to make the conversation a little messier. You’re both right and your both wrong… Honestly, I stop my reading on the 70th post.
On one side you have to practical @TomB, you’re failing here. There’s no business made of theory. Don’t get me wrong, I know what you mean by getting out the box and just rethink if the strategy is the appropriate.
@tony_marston404 , you need to get out of you shell, navigating on a 9000th line of code (or just opening in an editor will be a pain) and saying “it has to be” than you’re not thing it straight. Nothing “needs to be”. Is just like saying a sky scrapper is un-dividable. Well… in practice it is, but in fact you can think of floors, door, furniture, the structure (concrete, glass, iron… )
For both: nothing is right… nothing is wrong… it need to have a reason. A good practice by itself doesn’t mean anything if it doesn’t have a context. I won’t (probably) apply a SOLID principle to a 10 line batch to rename a file :). I won’t (probably) write a class with 200 methods for manipulating strings. Anything and everything makes sense couple but it can also make sense decoupled.
The questions are: Does it make sense? Have you though and discussed about it? Does it have stronger points that weaker points? Does it make sense to the business and is the business willing to pay for the investment of doing it right?
@TomB: the business doesn’t care how the software is made, it just wants the value of it and usually, they want it in a tight schedule and aren’t willing to negotiate or even understand your point of view, so the code needs it has to be dirty. There are scenarios, because of this, that DI can be evil because, there’s no question about it, it doesn’t make the drilling and navigation path fluid. You need to ask yourself “Which class implements this interface in this context”. And if you have legacy code that is highly couple… well trying to decouple it is a pain…
Also, trying to do DI for everything is not also practical, for every implementation you’ll need an interface, that almost “doubles” the work.
@tony_marston404, I regret that I didn’t make unit testing in some of my older programs because of business’s pressures, not good knowledge, just plain stupidity or laziness. Unfortunately some of the systems still live after 10 years and because I’ve lost the QA articles, because they weren’t written or because QA guy (that had that knowledge) left, I’m afraid of touching the code, and if I break… and it if does, can I detect it? Having quality unit tests pays of in the future (the unforeseen one), but this requires isolation and…. There’s no isolation if you can’t have DI.
Also, in my opinion you can’t pass a SQL query part to a business class and say it is decoupled… it isn’t, because … is part of an sql query, what if tomorrow you’re caching that entity or using a nosql or a redis backend ? Will it work?
Like I said, I stopped reading at the 70th post and don’t know if you really progress in the discussion (based on the last post you didn’t) so hopefully.
You’re both right… you’re both wrong. Use it wisely and with a reason.