4 Answers
4

Most of these answers are suggesting using the Singleton pattern or using static, but I disagree with this. Yes, this will get the job done, but IMHO, it's a bad practice. It's harder to test and isolate code that uses your Singleton/static code so it's not ideal. I'd use the Inversion of Control pattern/Dependency Injection pattern. Basically it works like this (Note that I come from a Java background):

Some other code is responsible for calling that setter. The code that calls the setter makes sure it only creates one instance of OneInstanceOfAClass and it passes that same instance into all the other classes you have with a setOneInstanceOfAClass method. As a result, there's only one instance of OneInstanceOfAClass but, OneInstanceOfAClass is not a Singleton and it doesn't need to use static anywhere. It's just a regular class that you only instantiate once.

Now it's really easy to isolate INeedOneInstanceOfAClass in a unit test. Your unit test creates INeedOneInstanceOfAClass and passes in a fake OneInstanceOfAClass that does whatever it needs to do to get out of the unit test's way.

I suggest make them static if you can, that is if your class doesn't have to save it's state. If it does, I think you can better make some kind of framework class that has one member of type INPUT. When you want to use the framework you instantiate a framework object, which instantiates one INPUT object. You drag that framework object everywhere you need the methods from INPUT. It's better debuggable and maintainable than a singleton. also, this: http://stackoverflow.com/a/138012/640888