Logging patterns from within library code

Question

I am looking for a design pattern for logging from within library code. Suppose I have a function in a library file that i expect will be used by multiple front-ends (lets assume a CLI and a web):

def foo(a,b):
 log("Processing a")
 p(a)
 log("Processing b")
 p(b)

Where would the foo get the "log" from? Should it:

1. Have an optional argument logger which supplies the object which implements log?
2. Consult a logger repository of sort - e.g logger.getLogger("mylibrary")
3. Always be part of an object (no static/class methods i.o.w) and the object be initialized with a logger as per (1)?
4. ...

Let's assume we're talking about a language with built in logging framework such as Python or a framework which is often used such as log4j in Java.

• Nick Alexeev: This link looks like it could be a useful read: docs.python.org/3.4/howto/… .
• Ewan: I go for option 1
• Konrads: @NickAlexeev cool, thanks - indeed Python logging hierarchy seems to be an elegant option.
• Konrads: @Ewan but why ? :-)

Answer 1

The most common approach is to pass the logger instance to your object via constructor or setter injection. Your library contains the Logger interface.

The consumers of your library can create their own logging implementation based on the interface in your library.

That way you can easily mock it for testing and make different loggers for each UI, so your CLI can log to the console and the web interface can log to a DB or whatever the requirement is.

• Simon: Or a little simpler would be a logging callback.
• RubberDuck: Or expose events so the client can log, if they wish, without your code needing to know a logger exists at all.
• Konrads: @RubberDuck do you have an example?
• RubberDuck: I don’t really have one handy, no. Are you familiar with event driven programming @Konrads?
• Konrads: @RubberDuck yes, a little, but that sort of presumes a very specific way of using a library that may be used in multiple ways