commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <sgarl...@users.sourceforge.net>
Subject Re: [logging] ECL: Log interface vs. abstract class
Date Mon, 20 Dec 2004 15:41:31 GMT
Let's make this more concrete by examining the problem currently 
presented to us: localization of logging messages (this would be API-X 
in your example).  If JCL adds a new LocalizedLog interface (JCL-IX), 
calls to the localized log will work as expected when the underlying 
logging implementation supports localization (branch 1 in your post). 
If localization is not available, the unresolved message keys are 
supplied to the underlying logging implementation (branch 2).

This seems perfectly reasonable to me.  If the underlying logging 
implementation doesn't support internationalization, then the log 
messages aren't internationalized.  Of course, if you've gone to all the 
trouble of making your message internationalized, I would expect this 
would narrow down the field of logging implementations you chose from :)

I hope I'm not being argumentative or dense.  I'm really just trying to 
make a case for using interfaces rather than abstract classes.  My point 
earlier was simply that the more features are supported by JCL, the 
harder it will be to squeeze them into some type of abstract class 
hierarchy and the more compelling an interface-based abstraction layer is.

Matt

Ceki Gülcü wrote:
> 
> Aren't you assuming that things can be placed in nice orthogonal and
> independent boxes?
> 
> Let X and Y be logging APIs that JCL attempts to abstract. Let IX be
> an interface unique to API X. Let JCL-IX be JCL's mirror of interface
> IX. If the end-user sprinkles her code with JCL-IX calls, there are
> two possible branches:
> 
> 1) API X is available, and there no unintended or unforeseen
> interactions between JCL-IX and IX then everything will be fine. If
> there are unintended or unforeseen interactions, then this usually
> takes a long time to discover, let alone to repair. In the mean time,
> your users will be pulling out their hair in frustration.
> 
> 2) API X is unavailable. In that case, JCL might may attempt to
> replace the functionality offered by API X with a NOP implementation or
> a simple alternative. However, if API X is considered core
> functionality, then the promise of abstraction cannot be not fulfilled
> without duplicating the code found in API X.
> 
> Writing a good facade is much harder than what people realize. In the
> case of competing and divergent APIs, it is an impossible one.
> 
> At 03:18 PM 12/20/2004, Matt Sgarlata wrote:
> 
>> I disagree; different logging APIs can be supported with the addition 
>> of new interfaces.  Using this strategy, the set of interfaces that a 
>> given Log implementation implements define the set of features which 
>> that logging implementation supports.
>>
>> Ceki Gülcü wrote:
>>
>>>
>>> Whether you choose Log to be an interface or an abstract class does
>>> not really matter. The point I am trying to convey is that jcl will
>>> not be able to abstract more than one logging API. Although desirable,
>>> abstraction is not technically feasible.
>>
>>
>> -- 
>> Ceki Gülcü
>>
>>   The complete log4j manual: http://qos.ch/log4j/


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message