[slf4j-dev] NOPLogger methods are final?

[Boris Unckel]

Hi,

just the other thread, it is getting late...

Eric Crahen wrote:
>
> On 2/15/07, *Boris Unckel* <boris.unckel.mlg at gmx.net 
> <mailto:boris.unckel.mlg at gmx.net>> wrote:
>  
>
>     I think for a common API like SLF4J it is very good to have
>     implementations final:
>
>     SLF4Js goal is to be used in libraries, other APIs and
>     applications. If there is need to change things,
>     the interfaces have to be stable. The implementations should still
>     have the chance to be changed WITHOUT
>     heavily caring about possible inherited classes.
>
>
> This is a "no-op" logger. I've carefully considered the fact that the 
> inherited implementations of all these components do nothing, and now 
> for the purposes of a test case I would like to add some assertions.
>
>     I.e. this is one major problem in the development of log4j - there
>     is so much usage that each very little change
>     has to be proven binary compatible. Thousands of people did not
>     care about using just interfaces and the SPI,
>     they just hacked "quick and dirty" with inheritation of classes
>     which were created with internal use intention.
>
>
> My code is still written only against interfaces. I'm extending an 
> implementation I've chosen to use for a test case.
Yes, it is written against an interface because the NOPLogger is final. 
If it was not final, you would inherit, right?
> I think this is a faily useful and straightforward test case that I 
> can not write today.
>
>     If someone has need to change something, the license offers full
>     rights to do that. Make a copy and change it.
>     Although there is the decorator pattern....
>
>
> I can tell you why I don't want to do the decorator pattern.
>
> The Logger and Marker APIs are actually quite lengthy and its more 
> than a few lines of code to implement them. To write the test above I 
> had to create a NullLogger and implement 49 methods that did nothing; 
> which the NOPLogger already does (attached). I don't see any value in 
> keeping the methods of NOPLogger final.
>
The benefit to make implementation classes of an API final is to have 
the chance to change. As a SLF4J developer you cannot change interfaces, 
but you
can change the internal behaviour of any final class as you as developer 
want to without breaking binary compatibility,
as long as you do not break the contract of the interface. Not breaking 
the contract is much easier to achieve and test as testing binary 
compatibility.

Regards
Boris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-dev/attachments/20070215/4eb3c3b7/attachment.htm>