On page 103, the code for FluentMailer provides a static method which is basically a service that (opaquely) instantiates a FluentMailer, gives the instance to a Consumer<FluentMailer> passed in by the caller in the form of a lambda, which is supposed to configure it, and then performs whatever operations are necessary to “send an e-mail” based on the configure FluentMailer.
The Consumer<FluentMailer> parameter is called block which is nondescript and maybe confusing. I suggest to call it configurator because that is what it is meant to do.
We also read:
Rather than creating an instance, users will now invoke
send()and pass a block of code. The send() method will create an instance, yield [?] it to the block, and, upon return, complete any required validations and perform its final send operations.
This may feel a bit roundabout, but we removed the smells we discussed earlier. The object’s scope is confined within the block, and once we return from the send() method, the reference is gone. We can also benefit from the fluent method chaining within the block, without the sour new keyword sticking out. Let’s use this new API in an example.
Suggesting:
Rather than create an instance to manipulate, client code will invoke the static
send()method, passing an instance ofConsumer.send()will create aFluentMailerinstance, call theConsumeron that instance, thus performing client-controlled configuration, then complete any required validations and finally perform its final send operations.
This may feel a bit roundabout, but we removed the smells we discussed earlier. The ‘FluentMailer’’s instance scope is confined to within
send(), there is nonewcall to be done anymore and we can benefit from the fluent method chaining to doFluentMailerconfiguration within theConsumer. Let’s use this new API in an example.