When to use dependency injection?
-
Dominic Burford wrote:
First off, stop wanting to be an ass kisser. No good ever came from wanting to kiss someone else's ass.
Well in "The Economist" they boasted the virtue of networking, which can be expediently describes as ass kisser... Clearly I need to work on my networking too, as I suffered greatly last year from expressing my opinion (main customer doesn't want me anymore) and nothing came out of it anyway! Further it appeared to me that skill and work will only take you so far...
Dominic Burford wrote:
Second, I'm always suspicious whenever I see a technology being used everywhere throughout an application. It makes me think that they don't really know how to use it properly.
I think so too! But it's obvious unless I can win the battle I better leave the boat or join the bandwagon. Arguing left me in a bad spot.. I'm tired of arguing... It only cause me trouble and people don't listen... Further I'm quite contended now, so I don't have a pressing need to find the best tool, I think I already played with it! ;P and I am ready to go on board financially with people who still resist them! :rolleyes: :laugh:
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
Super Lloyd wrote:
Further it appeared to me that skill and work will only take you so far...
All that matters is whether someone can sell it. Doesn't need to work well. Doesn't even need to run. But absolutely must sell. Unless of course you like working for free.
Super Lloyd wrote:
and people don't listen.
Yep. Realistically the idiom that you are using now is unlikely to adversely impact the running of the product. Costs more in maintenance and adds complexity. And in my experience over time it tends to make the code more like structured code and less like OO code. But none of that can be quantified as a real cost. Or at least it is a good bet that your company can't actually measure maintenance costs and never will. So just do it.
-
Regarding your INowResolver which as stated below it's understandable especially for testing. There are better ways to handle that. From ayende.com[^].
public static class SystemTime
{
public static Func Now = () => new SqlDateTime(DateTime.Now).Value;
}Then in tests
SystemTime.Now = () => new DateTime(2000,1,1);
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
Yeah, it's what I adopted in my own home made project! I want my home made library of utilities to work out of the box! I don't want to write lines of (obscure) initialization! :-D
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
While INowResolver seems like overkill, sometimes tests need to fix the time to get reproducible behavior. I find using the registry is similar, as are really any external data stores or sources of info, ie random numbers too. Unit tests should never rely on external input to work correctly. MUCH easier said than done. So I get it, and I also get where you're coming from. It's certainly a shock to the system when you're used to the ease of static methods. Good luck with it!