If you use a singleton I would at least provide a method to get access to the object, so if later you decide you can't use a singleton (say due to the singleton having state that varies by consumer) the change won't affect client code.
It seems people use singletons in 2 ways:
1) There should really only be one instance. For example in a model of our
solar system you would have one Sun, or in computer hardware you could only have 1 program listening on a socket.
Even this second example is debatable whether this needs to be a singleton, and in my opinion that is typical of Singletons. A singleton should be considered an implmentation detail and no one should write code assuming the implementation will always be a singleton.
2) For stateless or
thread save objects, developers sometimes use one instance to save on unnecessary creation of Objects. Again if you do this hide it.