|
I feel older every second of every day!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
|
|
|
|
|
Three college professors were driving down the highway at a very slow speed. A policeman pulled them over and explained that driving so slowly on the highway could be hazardous. The driver pointed out the sign that read "20." He explained that he was going 20 mph because of the sign. The policeman pointed out that the sign indicated they were driving on Highway 20.
Somewhat embarrassed the professor apologized and promised to be more observant.
As the policeman turn to walk back to his car, he noticed the other two professors on the floor ...looking scared to death!
He asked the driver, "What's wrong with them?"
The driver replied, "We just turned off Highway 105."
|
|
|
|
|
Scared to death? At 105 what? Miles per hour, I guess. That's a speed I reach only seconds after driving onto the Autobahn.[^] If traffic and weather permit, of course. Time to retire when I feel anything but pure joy when doing that. 
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
|
|
|
|
|
|
Twenty five years and one day ago,
Nelson Mandela walked into freedom, after 27 years.
|
|
|
|
|
My one political 'rant' for the year; And Jacob Zuma took only a few years to destroy all the good things Mandela did after his release. At this rate we will pull all of Africa into the dark ages before the end of the decade.
My plan is to live forever ... so far so good
|
|
|
|
|
I'm against making a fuss about terrorists being released from prison. Don't give them the attention.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
IMetaFactoryDependencyInjectionResolverFactoryProxyFactory, anyone?
Software Zen: delete this;
|
|
|
|
|
Oh you use that pattern?
It's alright but a bit too tightly coupled for some of our code! 
|
|
|
|
|
What do you get when you cross a joke with a rhetorical question?
---
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
---
Do questions with multiple question marks annoy you???
|
|
|
|
|
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!
|
|
|
|
|
al13n wrote: Good luck with it!
Thanks! :P
|
|
|
|
|
Has everyone written their Y2.038K unit tests yet? We don't want to wait till the last minute, like Y2K, when the legacy 32-bit time_t range is about to run out. 
|
|
|
|
|
I'm sure just like everything else it's going to become an anti-pattern.
I love it though. Not in the, "I'm going to use it everywhere!" way though. Like every coding choice there should be a good reason when you apply it.
In ways, it's one of my problems with async-await. It's great except how it creeps like a fungus where you don't want it. Not to get off topic.
|
|
|
|
|
Exactly! There is such a thing as too much of a good thing!
|
|
|
|
|
The rule of thumb I use is pretty simple. If i'm designing a class that depends on some other class, and there is a logical reason for that class to change either at runtime or in testing then I use dependency injection.
I also use DI when it makes sense to control something at runtime, such as a configuration entry, connection string, etc... or anything I might otherwise use a factory for.
Your example above for INowResolver seems kind of silly at first glance, but in reality, it's a great example of a DI resource. The problem with DateTime.Now is that you cannot alter this in testing, it always uses "Now" even when you might want to use a different time for "Now" (think when you want to test what happens in 2037 when the Y2037 bug hits, you can now substitute INowResolver with a different date/time for "now" to test what will happen in the future). Yes, you could write conditional code in your method to deal with this, but now you have test code in your methods, rather than in your test cases, which makes them messier and more difficult to maintain. There are also "Moles" or Proxy stubs that can replace the runtime behavior of methods like DateTime.Now, but not everyone uses those.
Your problem here is that you're not truly understanding the purpose of Dependency Injection, and as such you have a hard time understanding why it's used so much. You probably see it as a simple service locator or abstract factory service... injecting stuff so you don't have to bother typing "new". While it's true that you can use it for that, it really opens up a whole new array of possibilities when you "drink the Kool-Aid".
As for your Utility functions... in general, no.. you don't need to use DI for utility functions if there is no configuration or other dependencies involved. Particularly if they are pure static methods with no state.
--
Where are we going? And why am I in this handbasket?
|
|
|
|
|
No, my problem is always it COULD be used in theory to do... some special things...
Which I haven't seen BEEN put into practice...
(which is to be expected when there is a combinatory explosion of mock call to write equals to number of method to test times number of interface method to mock!)
But enough, I am not here to argue, on the contrary!
You love dependency injection! Wonderful! Me too! Gonna write no more public constructor or static class for the foreseeable future ever!
modified 12-Feb-15 1:49am.
|
|
|
|
|
First off, stop wanting to be an ass kisser. No good ever came from wanting to kiss someone else's ass.
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.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
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! and I am ready to go on board financially with people who still resist them!  
|
|
|
|
|
There is a wide gulf between networking and getting on with your colleagues, and ass kissing. Ass kissing is where you subjugate power and influence to another individual. Getting on with other people doesn't mean you have to agree with everything they say and do. I have many disagreements of opinion, but I am always assertive in expressing those differences, whilst simultaneously being courteous.
Stop ass kissing and start being assertive. You'll win far more respect.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
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.
|
|
|
|
|
Dominic Burford wrote: First off, stop wanting to be an ass kisser. No good ever came from wanting to kiss someone else's ass.
Too be fair a lot of this stuff normally only adds to maintenance costs and since the vast majority of organizations can't quantify maintenance costs anyways attempting to buck those in charge usually is nothing but a waste of time.
Dominic Burford wrote: It makes me think that they don't really know how to use it properly.
Yep.
|
|
|
|
|
I find it, in general, a pain in the arse.
Regards,
Rob Philpott.
|
|
|
|
|
When two ways work, but I find one, shall we say "inelegant", I do it both ways, and run performance tests.
Here's the important bit: If the performance tests show that my preferred way doesn't give a worthwhile improvement, I drop the subject.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
