When to use dependency injection?
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
IMetaFactoryDependencyInjectionResolverFactoryProxyFactory, anyone?Software Zen:
delete this; -
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! ;P
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
:doh:
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???
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }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!
-
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
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
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.
-
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!
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
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?
-
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!
All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
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
-
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! ;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!
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
I find it, in general, a pain in the arse.
Regards, Rob Philpott.
-
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!
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
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
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!
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
Use Dependency Injection wherever there will be a need to swap out an implementation. - Injecting different configurations - Dynamic loading of functionality - Replacing an implementation (eg repository) with a mockup for unit- or integration-testing Mocking up "Now" is a common thing for unit testing date sensitive stuff. There are dozens and dozens of articles about doing this, and it's a classic example of why using static methods (eg DateTime.Now) can get you in trouble when it comes time to test.
cheers Chris Maunder
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
I am currently working on my first greenfield project where I am using DI. I personally love it for testing purposes, but when it comes to utility classes THAT DON'T DEPEND ON EXTERNAL RESOURCES, I won't define an interface. Instead I'll just test their public API separately to know that the logic in that class is working as intended. I can then confidently test the code that uses that utility class as an external member.
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
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.
-
At work they are dependency injection crazy! Most of the classes they write implement a unique equivalent interface. And whenever someone else need the code in that class they will have the interface injected and use it. On the other hand I hate needless dependency injection and I write utility class which I just call directly when I need. One of my new year resolution is to be a better ass kisser / networker though! So... I am about to write a utility method which turn a file path into an HttpResponse. Should I make it an IProvideHttpResponse service? or should it remain a simple utility method? I kind of really struggle to see how far the stupid overuse of dependency injection should go.... :~ X| Mm... or maybe I should make an IUtility interface and put my mixed bag of utilities there? what's your thoughts? EDIT oh well, just for the sake of it, I implemented the IFileResponse service! :laugh: ;P EDIT2 I did just found this dependency injection gem in the code! :-o
public interface INowResolver { DateTime Now { get; } } \[Singleton\] public class NowResolver : INowResolver { public DateTime Now { get { return DateTime.Now; } } }All in one Menu-Ribbon Bar DirectX for WinRT/C# since 2013! Taking over the world since 1371!
Super Lloyd wrote:
what's your thoughts?
Not sure how often it occurs but it certainly often enough that I have seen people get 'stuck' on an idealization until it bites them - severely. Probably comes about when they are at the stage where every new idea seems 'fresh and new!' and they want to try all of them out but can only fit a few in. Then someone decides to impose it as a mandate. This isn't a new trend either. Plenty of examples in the past. One should use idealizations or even concrete technologies because they are useful now and not because they might be useful at some hazy point in the future. And they should be used with restraint.
-
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.
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.