InputManager: update member signatures to be static

Seeing as the InputManager is a singleton it makes sense that the members could/should be static.

Pros:

• InputManager.Method(); VS InputManager.Instance.Method();

Cons:

• Light refactoring. People would need to remove the Instance part of their code.

What do you guys think? Is there any other pros/cons I may have looked over? This change should not affect behavior in any way.

[maxouellet]

It wouldn’t really help: it actually makes it impossible to unit test your classes without taking a dependency on a specific implementation of the static class. Static methods make sense when you use them for generic math functions or similar functions that have no complex dependencies, but that isn’t the case for InputManager.

You are right that it doesn’t make a difference for integration tests.

Eventually, I assume we will also want to add optional features to the InputManager, or have alternate implementations. When/if that happens, having static methods would prevent these scenarios.

[maxouellet]

My two cents: I don’t really like this idea. Having static methods all over the place is pretty bad for isolating components and properly unit testing code. In fact, I’ve been trying to move away from singletons as much as possible across my project’s codebase for that exact reason. Instead of using singletons, I use some dependency injection to achieve a similar purpose in a more modular and decoupled way. While that solution might be too complicated for the HoloToolkit, moving to having static classes and methods completely breaks anyone that wants to do that.

You could also imagine that someone might eventually want to inherit from InputManager and add more functionalities to it. If you make it static, that makes this scenario impossible.

If you want to avoid having to call .Instance everywhere, you can always get the instance once in your Start method and cache it. That way, it’s super simple to switch how you retrieve the input manager (if it ever moves away from being a singleton, for example).