Design a simple Logger class. Should it be Static, Singleton, or injected via Interface? Justify.

Question

Accepted Answer

For production systems, I generally prefer an ILogger interface injected through dependency injection rather than making the logger static. Static logging is simple but creates global state and makes unit testing, replacement, and contextual configuration harder. A Singleton can centralize state, but dependency injection normally gives better lifecycle control and testability. The actual logging implementation can internally manage shared resources such as a file sink or logging pipeline. public interface ILogger
{
 void Info(string message);
 void Error(string message, Exception exception);
}

public sealed class ConsoleLogger : ILogger
{
 public void Info(string message) => Console.WriteLine(message);

public void Error(string message, Exception exception)
 => Console.Error.WriteLine($"{message}: {exception.Message}");
}

public class OrderService
{
 private readonly ILogger logger;

public OrderService(ILogger logger)
 {
 this.logger = logger;
 }

public void Process()
 {
 logger.Info("Processing order");
 }
} Prefer an interface plus dependency injection for application/business components. Static logging is acceptable for very small applications but creates global coupling. A Singleton may be appropriate for an infrastructure resource, but it should not be used merely to avoid dependency injection. Logging should support structured data, correlation IDs, log levels, and centralized configuration in distributed systems. Unit tests can inject a fake logger without changing business logic.

Design a simple Logger class. Should it be Static, Singleton, or injected via Interface? Justify.

Designing a Testable and Extensible Logger

Scenario Questions

Follow-up Questions