small medium large xlarge

Marco-closeup-alone_pragsmall
06 Feb 2014, 07:55
Marco Vermeulen (1 post)

Hi all,

For starters, I just wanted to say that I’m loving the book. It’s turning to be such a great resource, and really enjoying both the style as well as how thorough it is! Great job Venkat!

I have come across something small in one of the examples that might be worth revising, unless I misunderstood it of course :-)

It’s the example in chapter 4 about Fluent APIs. I noticed that the final solution on page 83 of the pdf only sets up the the FluentMailer, but does not actually perform any send action.

Would it be an idea to have a private void send() method that gets invoked in the public static final send() method after the FluentMailer has been initialised properly?

In other words:

    private void send() {}

and then:

    public static void send(final Consumer<Mailer> block) {
        final Mailer mailer = new Mailer();
        block.accept(mailer);
        System.out.println("Sending...");
        mailer.send();
    }

It’s just a small detail, and I’m not sure how far advanced the publishing process is, but thought I’d raise it none the less.

Keep up the great work! Marco.

Venkatsubramaniam_pragsmall
06 Feb 2014, 17:28
Venkat Subramaniam (97 posts)

Hi Marco,

Thank you so much for the kind words, that means a lot.

In the example you’re referring, the original implementation of send (instance method) simply had a symbolic print statement to indicate sending. In the modified version, that symbolic print has been moved to the static send, to indicate that method taking the necessary action. Much like how the original send would do whatever it has to, the send in the modified code would do as well, and it does have access to the mailer if needed.

In other words, our focus here is on the interface fluency instead of the implementation.

Thanks again for your encouragement and also the input.

Regards,

Venkat

Generic-user-small
06 Feb 2016, 02:04
Scott Stanlick (9 posts)

Venkat already knows I’m a book fan. However, I’m sort of with Marco on this one. I realize the book has printed (yay) but perhaps this forum might be a venue for those who still have inquiring minds after reading it :) On page 82 you point out some of the prior ugly such as calling a method more than once and as a reader still trying to mentally piece some of these new schemes together, I added the following tests to see what would be legal and/or result:

FluentEmail.send(mailer -> mailer.from(“s@g.com”).to(“t@g.com”)); FluentEmail.send(mailer -> mailer.from(“s@g.com”).to(“t@g.com”).to(“f@g.com”));

I also added the instance send() method as Marco suggested. Interesting to see that while duplicate calls are permitted, the final duplicate call trumps any prior.

Venkatsubramaniam_pragsmall
06 Feb 2016, 02:16
Venkat Subramaniam (97 posts)

Scott, whether duplication should be permitted or not is a separate design concern and should be properly handled by the implementation. The fluency in the design, in and of itself, does not concern with that issue. We need to tune the implementation under the interface to serve the needs of the particular design preferences.

You must be logged in to comment