Question

I would like to add a log to my application. I’ve picked a logging library but I’d like to be able to switch to a different library without having to alter any code that uses logging.

Therefore, I need some sort of logging wrapper that is flexible enough to utilize pretty much any underlying logging library’s functionality.

Any suggestions for such a wrapper’s design?

EDIT: one feature I must have in this wrapper is component tagging. I want my algorithm class to have "X:" appear ahead of its log lines, and my manager class to have "Y:" appear. How to propagate this these tags onto the underling log and how to build the component tag naming mechanism is one major design question here.

Answer 1

Your best bet is to make the interface as simple as possible. Completely separate the logging user’s interface from how the logging actually gets implemented.

Cross-cutting concerns always are expensive to maintain, so making things any more complicated will make you hate life.

Some library only wants something simple like this:

void logDebug(const std::string &msg);
void logWarning(const std::string &msg);
void logError(const std::string &msg);

They shouldn’t add or specify any more context. No one can use the information anyway, so don’t over design it.

If you start adding more information to your logging calls it makes it harder to reuse the client code that uses it. Usually you will see this surface when components are used at different levels of abstraction. Especially when some low level code is providing debug information that is only relevant to higher levels.

This doesn’t force your logging implementation (or even the interface the logging implementation conforms to!) into anything either, so you can change it whenever.

UPDATE:

Insofar as the tagging, that is a high level concern. I’m going to speculate that it doesn’t belong in the log, but that is neither here nor there.

Keep it out of the logging message specification. Low level code shouldn’t give a flying truck who you or your manager is.

I don’t know how you specify X or Y in your example. How you do that isn’t really obvious from the description we are given. I’m going to just use a string for demonstration, but you should replace it with something type safe if at all possible.

If this is always on, then just having an instance context (probably a global variable) might be appropriate. When you log in, set the context and forget about it. If it ever isn’t set, throw with extreme prejudice. If you can’t throw when it isn’t set, then it isn’t always on.

void setLoggingContext("X:");

If this changes at different levels of abstraction, I would consider a stack based RAII implementation.

LoggingTag tag("X:");

I’m not sure what your requirements are in the scenario when different stack frames pass in different values. I could see where either the top or the bottom of the stack would be reasonable for differing use cases.

void foo() {
  LoggingTag tag("X:");
  logWarning("foo");
  bar();
  baz();
}

void bar() {
  LoggingTag tag("Y:");
  logWarning("bar");
  baz();
}

void baz() {
  logWarning("baz");
}

Either way this shouldn’t affect how you add a message to the log. The baz function doesn’t have the context to specify the LoggingTag. It’s very important that using logWarning doesn’t know about tags for this reason.

If you wanted to tag based on some type, you could do something simple like this.

struct LoggingTag {
  LoggingTag(const std::string &tag_) : tag(tag_) {}
  template<typename T>
    static LoggingTag ByType() {
      return LoggingTag(typeid(T).name());
    }
  std::string tag;
};

void foo() {
  LoggingTag tag = LogginTag::ByType<int>();
}

This wouldn’t force someone to use typeid(T).name() if they didn’t want to, but gave you the convenience.