Panasonic Youth rob sanheim writes about software, business, ruby, music, stuff and things

Logging in an abstract base class - violates good OO?

Scenario: you are starting a project and have created three classes that all do their own standard log setup, creating private static logs or whatever. Does creating an abstract base type with standard logging functionality violate YAGNI, the single responsiblity principle, or something else?

A couple immediate problems I can see with the base type are too much coupling to the logging system for your objects, and having the bloated interface for objects that do not need the logging. Also, you’ll end up repeating yourself anyways when you have to extend base classes from frameworks.

I suppose this is really a case where I just want something like Ruby’s mixins.

Isn’t putting something like this:

private static final Log LOG = LogFactory.getLog(This.class);

at the top of each class that you’d like to “mixin” logging to, functionality equivalent to having a mixin?

It seems to me the problem has to do w/ debugging libraries. If they don’t log details about what they are doing you’re going to have a hard time fixing problems when it’s broken. Ruby modules allow you to re-use implementations across classes, but if the module doesn’t do any logging, the module mechanism itself doesn’t help eliminate framework/library/base class logging.

-pgm

HiveMind (the IoC container used by Tapestry) solves this on two prongs: Firstly, the most useful logging is provided by an interceptor that automatically logs all (or selected) method invocations, including parameters and return values.

Second, and this is important, if an *instance* needs to know its logger, it is injected in (via a setter method or constructor parameter). The logger’s name is based on the HiveMind service id rather than the logger’s class. This is not only proper (it seperates out the concern of naming and creating Log objects), but allows fine grained logging of just some instances (say when you have different services using different configurations but the same implementation class).

John: I don’t think so. You are tying yourself to the implementation of LogFactory, and if you want to change the logging system you are stuck (or have to go the clogging route, of course).

Howard: Sounds like the interceptor covers the 80% of pretty much what more people need, and I imagine it could be done in other containers using aspects…although that takes it out of the comfort zone of a lot of devs.