Does creating many static classes impact system performance?

Question

I’ve been creating many static classes to facilitate and clear code, 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 because just call:

GoogleTranslate.Translate("StackOverflow é a melhor universidade do mundo");

I have enough such classes to call APIS, as this is seen before professionals?

Answer 1

Yes, it gets faster, static classes do not need to instantiate, which has a non-trivial cost.

Static methods are like normal functions of any language, it is there ready for use. The advantage is that it has a surname (it is practically a namespace), then better organize the code. No need to allocate anything (normal class there is allocation even without being), no sophisticated mechanisms (except when it has been, but in general should not use global state). In static classes all methods shall be static.

It looks like something very different, but all languages that have not tried to sell themselves as 100% object-oriented, which is a fallacy, have always had, has always been useful and worked.

The gain is more by the static method than by the class. It is also true for static class methods who can be instantiated.

There are other characteristics of static classes, but they are not relevant and often even bad.

One of them is its construction. It occurs sometime before it is needed (it may not be on the load, but it may be, so a technique of Lazy loading can be interesting). Need to make sure that the coded form meets everything well, that does not exaggerate in the system load (rarely occurs), It is necessary to understand all implications to use correctly. Ideally it should not have a construction, but it can if necessary, useful and know what it is doing.

Those who like OOP say you should not use, 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 the test harder than make the main code harder to test.

If you ever need to change the strategy dynamically, it can become a problem, which is the same question as the test. If it is not something universal and unique the instance may be a better option.

Beware of variable global state in static or normal class. This works well in rare cases and needs to know what you are doing. Do not create a static class when the proper one is an instance. If you have been potentially varying at each run, create an instance.

Me and Stack Overflow abuse static classes :) Many say this is a terrible mistake, even if they don’t 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 work refactoring, usually compensate for the gain because in almost all cases I never needed to refactor.