Suppose for a moment that we were to choose between adding methods to the Log interface, and turning it into an abstract class with some methods; I don't understand what "real pain" would be incurred by having custom logging adapters be declared as:
The pain (as Robert pointed out) is that you preclude FooLog from extending any other class. (More below)
public class FooLog extends Logger {...} instead of the existing public class FooLog implements Log {...}
Sure there would be some inconvenience, but wouldn't it be the same as having to update the existing log implementation to add implementations for the new methods added to a Log interface?
Ideally instead of changing the existing Log interface, any new methods you want to add you introduce in a new interface (e.g. - EnterpriseLog).
If it's possible for EnterpriseLog to be implemented in terms of Log, all the better: existing implementations can have an EnterpriseLog exposed by using the Decorator pattern.
I really like this approach because it allows you to keep programming to interfaces rather than classes. For example, let's say that I had my own legacy CustomLogger that had some nice features I would like to keep when I migrate to JCL. CustomLogger participates in its own type hierarchy. All I have to do to integrate it with JCL is make it implement the Log interface. If Log is an abstract class, I have to take a sledgehammer to my CustomLogger to make it extend from Log and delegate calls to a SledgeHammeredCustomLogger.
I took this approach in Morph and I think it works quite well. Users only implement a simple Converter interface (similar to the one in BeanUtils). I have a separate interface called DecoratedConverter that exposes lots of extra methods that can all be implemented in terms of the basic Converter interface. If someone wants to expose their plain-old Converter as a DecoratedConverter, all they have to do is DecoratedConverter decorated = new ConverterDecorator(converter). This way, if I have an old Converter that participates in a type hierarchy already (say one that I wrote for BeanUtils), I can easily plug it into Morph by just implementing a new interface.
More below...
robert burrell donkin wrote: > does anyone think that there is any real need for implementations to > belong to a second type hierarchy?
I don't think it's a good idea to *preclude* logs from participating in two different type hierarchies because it's hard to anticipate new use cases.
But to answer your question, remember how Richard proposed that the generation of exception messages be possible with Logs? Well I think the community struck that idea down, but what if someone *did* decide they wanted to combine that functionality with their logger. In that case they would probably want to extend some type of message resolution base class rather than being forced to extend a Log abstract class.
> - robert
Matt
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
