On Wednesday 12 October 2005 08:24, Trustin Lee wrote: > This monitor pattern is overengineering IMHO.  Why should I add extra > methods whenever I write debug log messages and provide a bridge for known > logging frameworks?  And we can say using monitors is implementing AOP > almost by hand. If you take it at face value, and don't adopt it to your need, then I agree that it is over-engineered and an explosion of classes will result. However, there is a principle in there, which I find good. That you should isolate your dependencies to a single point if possible. And in case of logging, that is so simple to do. public interface OurLogger { // Add methods you need. boolean isDebugEnabled(); void debug( String message ); void info( String message ); void warn( String message, Throwable t ); void error( String message, Throwable t ); } public class OurLoggerBridgeToLog4J { private Logger m_logger; public OurLoggerBridgeToLog4J( Class cls ) { m_logger = Logger.getLogger( cls ); } public boolean isDebugEnabled() { return m_logger.isDebugEnabled(); } public void debug( String message ) { m_logger.debug( message ); } public void info( String message ) { m_logger.info( message ); } public void warn( String message, Throwable t ) { m_logger.warn( message, t ); } public void error( String message, Throwable t ) { m_logger.error( message, t ); } } public class OurLoggerFactory { public OurLogger getLogger( Class cls ) { // introduce some selector if needed. return new OurLoggerBridgeToLog4J( cls ); } } Ok, that took ~10 minutes. To be more embeddor friendly, introduce a delegation mechanism in the OurLoggerFactory. Ok, that will take another 10mins. Considering the reduction of depending on external stuff to a single point (one class + a factory), the amount of effort required is neglectable. THAT is what I kept from Hammant's insight. And I am a bit surprised that more people doesn't see the beauty of this ;o) Cheers Niclas