I'm not following at all what you are saying. 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.
* 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. * 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. On 2/15/07, Boris Unckel <[EMAIL PROTECTED]> wrote:
Hi, just the other thread, it is getting late... Eric Crahen wrote: On 2/15/07, Boris Unckel <[EMAIL PROTECTED]> 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 _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
-- - Eric
_______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
