I don't see the benefit either...
The goal of a fluent interface is to be able to combine many calls (usually on
different objects) into a chained call that can be on a single line and reads
like English.
The canonical example is: (before)
{code}
private void makeNormal(Customer customer) { Order o1 = new Order();
customer.addOrder(o1); OrderLine line1 = new OrderLine(6, Product.find("TAL"));
o1.addLine(line1); OrderLine line2 = new OrderLine(5, Product.find("HPK"));
o1.addLine(line2); OrderLine line3 = new OrderLine(3, Product.find("LGV"));
o1.addLine(line3); line2.setSkippable(true); o1.setRush(true); }
{code}
After:
{code}
private void makeFluent(Customer customer) { customer.newOrder() .with(6,
"TAL") .with(5, "HPK").skippable() .with(3, "LGV") .priorityRush();
}
{code}
I don't think this is necessary in the logging API because we *already have a
single call*.
{code}
Logger.error("Error while ordering {} {} and shipping to {}", 5, "bread
baskets", "France", caughtException);
{code}
Splitting this up into multiple calls so we can call it fluent is not an
improvement.
There is no complexity that needs to be simplified IMO...
Remko
________________________________
From: Ralph Goers <[email protected]>
To: Log4J Developers List <[email protected]>
Sent: Tuesday, July 30, 2013 7:45 AM
Subject: Re: LOG4J2-242 (Fluent Logging)
I actually started to work on this myself several weeks ago and came to the
conclusion that I just couldn't grasp how it is better - with one exception.
You can reuse the MessageBuilder and replace the message or arguments, etc. But
that seems dangerous as it wouldn't be thread safe.
Ralph
On Jul 29, 2013, at 1:48 PM, Gary Gregory wrote:
On Mon, Jul 29, 2013 at 4:39 PM, Nick Williams <[email protected]>
wrote:
>
>I'm working on LOG4J2-242 to add the ability to log fluently. It's going to
>work something like this:
>>
>>interface Logger:
>> + MessageBuilder trace();
>> + MessageBuilder debug();
>> + MessageBuilder info();
>> + MessageBuilder warn();
>> + MessageBuilder error();
>> + MessageBuilder fatal();
>> + MessageBuilder log(Level);
>>
>>+ interface MessageBuilder:
>> message(String);
>> message(Object);
>> message(String, Object...);
>> marker(Marker);
>> exception(Throwable);
>> argument(Object);
>> arguments(Object...);
>> log();
>>
>>Bruce (the requester) had suggested adding the methods that return
>>MessageBuilder to a different interface (as opposed to Logger) to keep from
>>cluttering the Logger API. The way I see it our options are:
>>
>>- Create a FluentLogger interface to house these methods. I don't like this
>>option because A) it complicates things significantly, B) it makes users have
>>to call a different method on LogManager (getFluentLogger) to get a
>>FluentLogger, and C) it means users have to have a Logger and a FluentLogger
>>if they want to use both APIs.
>>
>>- Create a FluentLogger interface that extends Logger. This option is much
>>better. It avoids cluttering the Logger API if that's all someone wants to
>>use, it doesn't require someone to have a Logger and FluentLogger if they
>>want to use both APIs, and it doesn't complicate the implementation
>>significantly (all implementations can just implement FluentLogger). It does
>>still mean LogManager (and related classes/interfaces) need getLogger and
>>getFluentLogger methods, which I don't necessarily like.
>>
>>- Just add these methods to Logger, which is what I intended to do from the
>>get-go and is what I still think is the best option.
>>
>
>
> - and there's option 4: Don't do it.
>
>
>At first glance, adding these methods to Logger looks confusing and cluttered.
>The less messy solution seems to me FLogger extends Logger.
>
>
>
>Gary
>
>
>
>>I'm going to proceed with #3 for now, but if someone has a strong opinion
>>otherwise please voice it so that we can discuss before I complete this.
>>
>>Nick
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [email protected]
>>For additional commands, e-mail: [email protected]
>>
>>
>
>
>--
>
>E-Mail: [email protected] | [email protected]
>Java Persistence with Hibernate, Second Edition
>JUnit in Action, Second Edition
>Spring Batch in Action
>Blog: http://garygregory.wordpress.com
>Home: http://garygregory.com/
>Tweet! http://twitter.com/GaryGregory
