Which design pattern would you consider when Logging is needed?

Question

An application I'm working on requires logging of actions, user who performs the action, and time of action to a database.

Which design pattern is most popular/appropriate for logging?

I'm thinking of Command pattern that require the current user and an action. Perform the action and write to the log.

What do you think? Any other alternatives I can consider?

Thank you.

Answer 1

You can use AOP to apply logging without any intrusive behavior. AOP may feel like a mixture of Proxy and Decorator Pattern.

Answer 2

Observer Pattern is well suited for logging framework. You can have Logger class extending Observable, and child classes like log to console, log to Database and log to File system etc and each child class implements Observer. Now whenever a log message is logged all the observer classes registered with Logger class will be notified so that each Child class ex: log to console will log the message to console. Also Logger class can follow Singleton pattern to make sure a single instance of Logger is available through out application.

Answer 3

Don't conflate the Command and the logging Memento.

The Command is something that gets done. Which may include some common aspects across all commands, including writing a log entry.

The log entry itself may be a Memento or a summary of a Memento.

The logger is a kind of Factory, which creates Mementos for logged events.

As with most things, you have a large number of interlocking design patterns. Which "one" pattern is "most popular/appropriate" doesn't enter into it.

The question is "what is supposed to be happening?"

Answer 4

I agree, I think the command pattern would fit the most since you would have all the action listed.

But I don't think that you really need to follow a design specific pattern for this one.You can simply set a callback on the actions to update the log. It depends on your architecture and technologies but out of my head the command pattern sounds like overkill.