design patterns - Why we should consider the «Logger» class as a singleton?

Question

We all know about log, ok, but why should we consider the ?Logger? class a singleton one? What happens if we make it as a normal non-singleton class?

Answer 1

I found this here on the IBM site. It explains the usage of a Logger Singleton class quite well.

A classic example of a true singleton is a logging service. Suppose we have an event-based logging service: Client objects request that text be logged by sending a message to the logging service. Other objects actually log the text somewhere (console, file, whatever) by listening to the logging service for these logging requests and handling them. First, notice that the logging service passes the classic test for being a singleton:

• The requesters need a well-known object to which to send requests to log. This means a global point of access.
• Since the logging service is a single event source to which multiple listeners can register, there only needs to be one instance.

Here the link: Use your singletons wisely

If you wouldn't use a singleton class you would have to deal with the synchronisation (writing to a file, or whatever stream you use) between these different logger instances. So its much easier, when you just have one global Logger instance.