CODEWITHSUNDEEP
c#classoopmethodsstatic
Abe A.
Abe A.

Reputation: 15

Multiple calls to external static method OR call one internal method, that calls the external static

So my question is:

I got a static class with a static method called:

static class A() {
     public static MethodA() { }
}

and I got another class that will call the MethodA() of the static class multiple times:

static class B() {
     public static MethodB1() {
         MethodA()
     }
     public static MethodB2() {
         MethodA()
     }
     public static MethodB3() {
         MethodA()
     }
     public static MethodB4() {
         MethodA()
     }
}

Is this the right approach or should I do it like this (call internal function, which is the only reference to the static method):

static class C() {
     public static MethodC1() {
         StaticCaller()
     }
     public static MethodC2() {
         StaticCaller()
     }
     public static MethodC3() {
         StaticCaller()
     }
     public static StaticCaller() {
         MethodA()
     }
}

I came up that this is a design or philisophy question but is there any technical advantage, like maintainable or scaleable code?

Edit: Or even performance improvements?

Upvotes: 0

Views: 793

Answers (2)

Christopher
Christopher

Reputation: 9824

Wim ten Brink wrote the answer I would have, so at best I can make additions to what he said:

I loathe working with statics. Replacing the call to one static with the call to another is a pain. For that reason I prefer C. It makes it easy to replace.

But I do actually have two other options that may be worth considering:

1st

As I loathe statics, I try to avoid writing them. And all of your classes are still statics, passsing the Problem down. If I need something like this and it has any non-constant field, I would not make it a static. I would instead make it a normal instance-requiring class. And then make a static field that takes a instance of this class. It might not sound like that differnce, but replacing:

static staticsProvider SP = new ImplementationA();

with

static staticsProvider SP = new ImpelentationB();

Allows a quick swap. Also if you ever need two or more different instances for different pieces of codes (SP1 and SP2), this is now just one additional static field and instnatiation away. Those are the two big issues of statics taking care off. And you could still use instances in class or function scope too.

Now the WPF way is "If you can not change it, wrap it into something you can change!". So how about option D:

//I am not a static
public class D{
    //I am not either
    public void MethodA(){
      //But I do call one for you
      A.MethodA();
    }
}

You can then create a static field:

static public D SP = new D();

If you need more then one static provider? make another field. If you need a different implementation? Extract a Interface (actually a VS IDE Option) or create a abstract baseclass from D. change the variables to said baseclasss/Interface. Then make a class D2, wich inherits/implements from what you just created.

Do not want it to change at runtime? const or readonly modifiers. But actually the abiliy to exchange instance at runtime might be a feature.

2nd

Rather then trying to cut down on calls for static, how about cutting down on versions of MethodBX and MethodCX?

By using delegates you could hand in the code for the "beforeStatic" and "afterStatic" parts as functions.

This is however only adviseable for really small differences. If you got large differences, writing two large delegates for each call would make it less manageable then just writing the mutliple functions you got now.

Function call overhead

There is a cost to calling functions. In effect the CPU has to make a jump. And jumps are still a thing whose cost can be measured. It will propably not mater in the big picture - we are way past the time we pinched CPU cycles. Also, it might be avoided autoamtically:

Native C++ has the inline compiler hint.

Afaik .NET does not allow this control. But it does have the JiT and Compiler Optimisations. And those can totally go and inline for your automatically. And for a function like this:

public static StaticCaller() {
  MethodA();
}

Let me just say that if there are any function to be inlined, the ones that look like this have to be on the top of the list.

Upvotes: 0

Wim ten Brink
Wim ten Brink

Reputation: 26682

This is considered opinion-based as both methods have their own advantages. Many developers here on SO have their own preference so this is challenging to answer without voiding an opinion.
In class B each call goes directly to method A while in class C the call first has to go through a local method before it can go to method A. This extra step can be considered redundant and thus class B would be preferred.
However, for whatever reason you might have to change the call from method A to method D, from a class you haven't made yet. In that case, you would have to change four methods in class B and just one in class C. Thus class C is easier to maintain and adjust.
Both thus have their pros and cons and class B gives a very minor performance gain. (Literally clock ticks!)
So in general, it really doesn't matter much so my advise is to pick the solution that is best to read for developers. This means adding comments, use proper formatting, use clear method names and try to avoid repeating yourself!
And that latter comment means that both class B and class C are bad practice as each class is repeating a call to some method. You should reconsider reshaping those methods into a single method. Which can be tricky as there might be a lot of differences in these methods.

Upvotes: 1

Related Questions