Factory methods (was Re: [slf4j-dev] SLF4J Implementation for Simple Log)

[Curt Arnold]

On Aug 10, 2005, at 11:20 AM, Ceki Gülcü wrote:

> At 02:51 PM 8/10/2005, Graham Lea wrote:
>
>
>> Name changes don't really bother me, but I don't really like  
>> single-letter prefixes in class/interface names. (That's a  
>> personal preference.)
>>
>
> Agreed. LoggerFactory would be a better name but its already taken.
>

At this point, I would think that SLF4J would still be malleable.



>
>> I think it's misleading in this case because LoggerFactory doesn't  
>> implement ILoggerFactory, which might throw a lot of people.
>>
>
> Quite true. The fact that LoggerFactory (offering only static  
> methods) does not implement ILoggerFactory is not really nice but  
> that seems more like an unavoidable language constraint.

Going directly from a static LoggerFactory to a Logger eliminates the  
possibility of doing any feature sniffing on the factory.  For  
example, if we define LoggerFactory with some essential set of logger  
accessor methods, there is not a mechanism for an implementation to  
offer any additional logger accessors.

The javax.xml.parsers package might be a good pattern.  They have a  
three stage approach: DocumentBuilderFactory to get a DocumentBuilder  
that can get a Document.  If that naming pattern was carried over,  
you'd have something like:

class LoggerBuilderFactory {
      static LoggerBuilder newLoggerBuilder();
}

interface LoggerBuilder {
     Logger getLogger(String name);
}

interface Logger {
      void debug(String msg);
}

Using Hierarchy instead of Builder and getHierarchy instead of  
newLoggerBuilder might make it more familiar to the user community.   
For example, an implementation implemented on top an OSGi  
implementation might define their LoggerBuilder like:

interface OSGiLoggerBuilder {
      Logger getLogger(ServiceReference ref);
}

class OSGiLoggerBuilderImpl implements LoggerBuilder,  
OSGiLoggerBuilder {
}

That way if code that wanted to use the configured SLF4J  
implementation, but use OSGi specific features if they were available  
could do something like:


Logger getLogger(ServiceReference service) {
    LoggerBuilder loggerBuilder =  
LoggerBuilderFactory.newLoggerBuilder();
    if (loggerBuilder instanceof OSGiLoggerBuilder) {
       return ((OSGiLoggerBuilder) loggerBuilder).getLogger(service);
    }
    return loggerBuilder.getLogger(service.toString());
}