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?

Solution 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.

Solution 2

The main problem is where the actual log is persisted.

If you are writing on a filesystem, having more than one instance (and therefore, probably, more than one thread) may result in a garbled file.

In the sense that depending on buffering and other low-level mechanisms messages from one write may end up mixed with messages (or parts of messages) from others.

This may be a minor problem, but it's the only one I can think of regarding having just one (and therefore serial) log writing object.

Solution 3

If you have more than one log streams with different content, you can use multiple instances of the logger class initialized for the different outputs.

However, if you have only one log stream, having multiple logger class instances leads to more complex implementation, as the instances have to work together to manage the actual resource. Consider for example a logger that logs each message with a sequence number. Two instances will have to synchronize their sequence counters, which requires them to knwp about each other, negotiate counter increases and so on. (The alternative of having shared counter in a static class member is equivalent to having a singleton logger)