I've been creating many static classes to make code easier and cleaner, such as a Google Translate API call.
public static class GoogleTranslate
{
public static string Translate(string word){
//código de chamada
}
}
Doing so is much easier, just call:
GoogleTranslate.Translate("StackOverflow é a melhor universidade do mundo");
I have enough classes like this to call APIS, how is this seen in front of professionals?
Yes, it gets faster, static classes do not need to instantiate, which has no trivial cost.
Static methods are like normal functions of any language, it's there ready for use. The advantage is that it has a last name (it's practically a namespace ), so it organizes the code better. You do not need to allocate anything (normal class there is allocation even without having been), it does not have sophisticated mechanisms. In static classes all methods must be static.
It looks something very different, but all languages that have not tried to sell themselves as 100% object-oriented, which is a fallacy, have always had and always been useful and worked.
The gain is more by the static method than by the class. It is also valid for static methods of classes that can be instantiated.
There are other static class features, but they are not relevant and often even bad.
One of them is the construction of it. It occurs at some point before it is needed (it may not be in the load, but it may be, so a lazy loading technique may be interesting). You need to make sure that the coded form goes well, that it does not exaggerate in the system load (rarely occurs), you have to understand all the implications to use correctly. Ideally you should not have a construction, but you can if it is necessary, useful and know what you are doing.
Who likes OOP says they should not use it, I come from a more pragmatic school that does what it should do.
It's harder to test, but not impossible. I'd rather make it harder to test than to hinder the main code to make testing easier.
If one day you need to dynamically change the strategy, it can become a problem, which is the same as the test. If it is not something universal and unique the instance may be a better option.
Caution with variable global state in the static or normal class. This works well in rare cases and you need to know what you are doing. Do not create a static class when appropriate is an instance. If it has potentially varied with each run, create an instance.
I and Stack Overflow abuse static classes :) Many say that this is a terrible mistake, even if they do not know our context. When it has to be an instance, I do it. Most of the time if one day I need to change, I refactor (I can do this, not everyone can), even in cases that give refactoring work, it usually compensates for the gain because in almost all cases I never needed to refactor. / p>