How do I share code between static classes?

Question

I have two very similar static classes, that I would believe should share the same code base, but I keep running in to limitations in c#.

Interfaces can't declare static methods, static methods can't be virtual etc.

Ultimately I just want a nicer looking version of the following:

public class StaticCoroutine {
    private static MonoBehaviour runner;

    public static void Start(IEnumerator coroutine) {
        if (runner == null) {
            runner = new GameObject("[Static Coroutine Runner]").AddComponent<StaticCoroutineRunner>();
        }
        runner.StartCoroutine(coroutine);
    }

    public static void Stop(IEnumerator coroutine) {
        if (runner != null) runner.StopCoroutine(coroutine);
    }
}

public class StaticCoroutineInfinite {
    private static MonoBehaviour runner;

    public static void Start(IEnumerator coroutine) {
        if (runner == null) {
            runner = new GameObject("[Static Coroutine Infinite Runner]").AddComponent<StaticCoroutineRunner>();
            Object.DontDestroyOnLoad(runner.GameObject);
        }
        runner.StartCoroutine(coroutine);
    }

    public static void Stop(IEnumerator coroutine) {
        if (runner != null) runner.StopCoroutine(coroutine);
    }
}

Suits [codereview](http://codereview.stackexchange.com/) better. — Sinatr, Dec 18 '15 at 12:48
Maybe you should post this on http://codereview.stackexchange.com/ — rory.ap, Dec 18 '15 at 12:48
Start from the assumption to avoid statics as much as possible. In most cases there is no reason to use them. Doing so will make your code more modular and testable. — L-Four, Dec 18 '15 at 12:49
Why insist on static then? Is the convenience of global access worth the downsides? It seems that all your problems go away by using an instance rather than a static class... Worth thinking about... — spender, Dec 18 '15 at 12:49
Looks like Unity to me, which uses static in a lot of places. — SBI, Dec 18 '15 at 12:51
Let's just say I don't desperately need a solution. I do want to do this with those static classes, for now. — Steinbitglis, Dec 18 '15 at 12:52
@SBI I've seen a lot of rotten codebases that grew out of the mindset of "someone did this before me therefore let's keep on doing it". — spender, Dec 18 '15 at 12:52
@Steinbitglis: Then what is your question exactly? What do you mean with 'nicer'? — L-Four, Dec 18 '15 at 12:53
@spender Oh I've seen my fair share of that as well. But there's a difference between "I shouldn't be doing it this way" vs "The engine tells me to do it this way". — SBI, Dec 18 '15 at 12:54
@L-Three can I use inheritance, or some other technique to implement those two classes with a shared code base? — Steinbitglis, Dec 18 '15 at 12:54
@SBI I recognised it was Unity as well and therefore looked up the coroutine documentation. No where does it mention using static. http://docs.unity3d.com/Manual/Coroutines.html — Aron, Dec 18 '15 at 12:56
@L-Three no would be a perfectly good answer... if it isn't possible. — Steinbitglis, Dec 18 '15 at 12:56
@Aron Thanks for looking that up, then of course there's no reason for this being static. At least with the context provided. — SBI, Dec 18 '15 at 12:58
Its possible. You can just use the `Singleton` anti-pattern instead of using `static`. — Aron, Dec 18 '15 at 13:00
Inheritance doesn't work with static classes by design, see http://stackoverflow.com/questions/774181/why-cant-i-inherit-static-classes. — L-Four, Dec 18 '15 at 13:03
To be quite frank with you, looking more closely at your code, you seem to be trying to implement the `strategy` pattern. But the point of the strategy pattern is that you can...umm..choose the strategy based on the circumstances, which would require you to pass an INSTANCE of that strategy about. — Aron, Dec 18 '15 at 13:08
This class used to be one with a bool to control the behaviour. This looked nicer in some ways, but I know very well than either of those solutions aren't perfect. — Steinbitglis, Dec 18 '15 at 13:14

spender · Answer 1 · 2015-12-18T13:06:07.820

It looks like you're just retrotting the old singleton conundrum by your insistence that this remains static. static is the enemy of modularity.

I'd really advise against this... you should aim to supply services as dependencies that can be injected, even if you don't use IoC/DI.

Assuming that you're not willing to completely refactor right now, I would suggest moving all functionality into an instance-able class and providing a static accessor to an instance of that class.

 public class MyThing : SomeBaseClass, ICanImplementInterfaces
 {
     private Lazy<MyThing> myThingLazy = new Lazy<MyThing>(() => new MyThing())
     public static MyThing Instance
     {
         get
         {
             return myThingLazy.Value;
         }
     }
 }

At least now, when you upgrade your architecture, you won't be left with a bunch of hard to maintain/test statics, or even worse, classes that refuse to instantiate more than once.

Well, thanks for your effort. I had to ask, so that I could convince myself that I hadn't overlooked some simpler solution. This class is unlikely to be changed without a rewrite... the difference this time is that I wanted to learn something. — Steinbitglis, Dec 18 '15 at 13:11

How do I share code between static classes?

1 Answers1