Using Static Events vs Static Instances

Hello

For singletons, is it better to make their events themselves static or to have a static Instance variable? For example, I have an InputManager. If I have an event "Fire1ClickedEvent", would it be better to declare that event as static or have a static Instance variable for the class?

If the event was static, other scripts would access the event using: InputManager.Fire1ClickedEvent.

If their was a static Instance, other scripts would access the event using: InputManager.Instance.Fire1ClickedEvent.

Making the events static makes it simpler to access, but I've been told that static events are "bad" or shouldn't be used often.

Thanks!

 

If you made the event static, you would diminish the (alleged) 'benefit' of a Singleton.

 

For consistency, you should keep everything instanced and just use the static "Instance" reference to access them. The point of singletons over static non-Monobehaviour classes is to allow you to continue to use drag-and-drop functionality in the inspector for assigning references, use of coroutines, and consistent/reliable object construction timing. Since one of the common features of singletons is the automatic destruction of further instances of the object, there's really no need for anything else to ever be static.

 

There are a lot of different ways to approach static. All of them bad. You are left choosing between which method is the least bad for your use case. Here are three basic approaches.

- Hand out references directly to your instance variable through a static reference. This tends to be a little messy. It also tends to lead to more coupling then you would normally desire.
- Use a set of static references for each method and variable. This is actually pretty good for things which are genuinely static, like input managers. It also lets you hide some of the implementation details, you can direct a static method to an instance method or not, however you choose.
- Hand out smaller interfaces directly through a static reference. This is my preferred method at the moment. This actually gives you a fair bit of freedom to choose how you manage the implementation, you can make a system that behaves kind of like a singleton, without having to go all the way. It also reduces coupling.

 

I don't personally have any issue with static as long as the class is truly a good candidate for static behaviors. The rationale gets hairy when you start mixing static and instanced behaviors in the same class, but there are plenty of valid use-cases for those, too. (Simple example: store the results of a lot of Quaternion calcs once in static members, and later the instances reference them as needed -- no value in wasting space with copies of those same Quat results in every instance.)

@Lysander makes some good points but only the constructor consideration matters much if your class is not a Monobehaviour.

The right time to use static is like the definition of porn: you'll know it when you see it. The OP's example of using the Instance getter looks a lot like a static candidate to me, but it really depends on the overall content and behavior of the class. I would say Instance makes sense if the caller needs to get and keep that reference to Instance and do multiple useful things with it. Don't use Instance as an extra step to accomplish the same thing merely because you've heard "static = bad"... design the class, not the call.

(Static is starting to look like the "goto" statement for the 21st century. It gets abused, and suddenly everybody avoids it unilaterally. And yet where would we be without the "goto" of the 70s... assembly jumps? But I digress...)