I'm not following at all what you are saying.<br><br>My point was, it is very intiutive and straight forward to derive from a Null Object implementation of a Logger for the purposes of testing. This is not possible because the NOPLogger included in SLF4J has all methods final. This means I would have to create my own Null Object implementation that is not final so I can override methods in a derived class. This requires writing no less than 49 methods that aren't fun to write.
<br><br>* The clear draw back to the NOPLogger containing methods is that it can not be extended. This directly impacts testing with out of the box the standard SLF4J classes. <br><br>* The clear advantage is that with non final methods I do not have to write a whole new class, or some how modify the SLF4J distribution to get an extensible NOPLogger. This means that people can very easily write unit tests to ensure messages are logged properly by an application as the code I posted previously demonstrates.
<br><br><br><br><div><span class="gmail_quote">On 2/15/07, <b class="gmail_sendername">Boris Unckel</b> <<a href="mailto:boris.unckel.mlg@gmx.net">boris.unckel.mlg@gmx.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
just the other thread, it is getting late...<br>
<br>
Eric Crahen wrote:
<blockquote cite="http://mided0c429e0702151341v3616d88bg27248efaaee47730@mail.gmail.com" type="cite"><br>
<div><span class="gmail_quote">On 2/15/07, <b class="gmail_sendername">Boris Unckel</b> <<a href="mailto:boris.unckel.mlg@gmx.net" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">boris.unckel.mlg@gmx.net
</a>>
wrote:</span>
<div> </div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">I think for a common API like
SLF4J it is very good to have
implementations final:<br>
<br>
SLF4Js goal is to be used in libraries, other APIs and applications. If
there is need to change things,<br>
the interfaces have to be stable. The implementations should still have
the chance to be changed WITHOUT<br>
heavily caring about possible inherited classes.</div>
</blockquote>
<div><br>
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.
<br>
</div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">I.e. this is one major
problem in the development of log4j - there is
so much usage that each very little change<br>
has to be proven binary compatible. Thousands of people did not care
about using just interfaces and the SPI,<br>
they just hacked "quick and dirty" with inheritation of classes which
were created with internal use intention.</div>
</blockquote>
<div><br>
My code is still written only against interfaces. I'm extending an
implementation I've chosen to use for a test case.<br>
</div>
</div>
</blockquote>
Yes, it is written against an interface because the NOPLogger is final.
If it was not final, you would inherit, right?<br>
<blockquote cite="http://mided0c429e0702151341v3616d88bg27248efaaee47730@mail.gmail.com" type="cite">
<div>I think this is a faily useful and straightforward test case
that I can not write today. <br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">If someone has need to change
something, the license offers full rights
to do that. Make a copy and change it.<br>
Although there is the decorator pattern....</div>
</blockquote>
<div><br>
I can tell you why I don't want to do the decorator pattern.<br>
<br>
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.
<br>
</div>
<br>
</div>
</blockquote>
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<br>
can change the internal behaviour of any final class as you as
developer want to without breaking binary compatibility,<br>
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.<br>
<br>
Regards<br>
Boris<br>
<br>
</div>
<br>_______________________________________________<br>dev mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:dev@slf4j.org">dev@slf4j.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://www.slf4j.org/mailman/listinfo/dev" target="_blank">
http://www.slf4j.org/mailman/listinfo/dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><br>- Eric