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
