[
https://issues.apache.org/jira/browse/FREEMARKER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15641873#comment-15641873
]
Brian Pontarelli commented on FREEMARKER-39:
--------------------------------------------
Technically you are correct that it is a builder (via GOF and others) since it
builds things. I should have been more explicit and said that it isn't a
standard Java style builder. I don't think there are many classes in Java that
are named Builder that aren't fluent. Locale.Builder, Calendar.Builder,
StringBuilder, etc. Not to mention all the fluent builders in third-party
libraries: Guava, Commons, etc.
Also, the JavaBean specification is fine to stick to but not necessary for
Builders by design. Builders aren't usually designed to be used via reflection.
Many of the JDK builders and other systems use setters for the method names.
However, like you said, you can add additional methods.
I will argue that providing a Fluent interface does reduce code, makes inlining
possible and will save people time. Plus, it just feels better almost all the
time. Imagine the JDK Stream interface not being fluent. Ouch.
I'm definitely looking forward to FreeMarker 3.0 (and maybe semantic
versioning). I think there are a lot of opportunities to clean house with a
major release like that. Let me know if you want a 10 year user's input on all
the stuff that's "challenging" from the API and template language. I'm sure you
know most of it already though.
> DefaultObjectWrapperBuilder isn't a Builder
> -------------------------------------------
>
> Key: FREEMARKER-39
> URL: https://issues.apache.org/jira/browse/FREEMARKER-39
> Project: Apache Freemarker
> Issue Type: Improvement
> Components: engine
> Affects Versions: 2.3.25-incubating
> Reporter: Brian Pontarelli
>
> This might not be considered a bug, but I'm logging it as one rather than an
> improvement. The class {{DefaultObjectWrapperBuilder}} is not actually a
> builder right now and it makes using it inline impossible.
> To make it a more standard Builder pattern, all of the setter methods should
> be updated so that the return type is {{DefaultObjectWrapperBuilder}} and the
> method does a {{return this;}} at the end. This will make method chaining
> possible and inline use also possible. Since it uses inheritance extensively
> (you might want to consider unwinding this as well), you'll need to use
> generics and return T. Here's the class definition so that T works:
> {code:title=DefaultObjectWrapperBuilder.java}
> public class DefaultObjectWrapperBuilder extends
> DefaultObjectWrapperConfiguration<DefaultObjectWrapperBuilder>
> {code}
> And the parent class is defined like this:
> {code:title=DefaultObjectWrapperConfiguration.java}
> public abstract class DefaultObjectWrapperConfiguration<T> extends
> BeansWrapperConfiguration<T> {
> {code}
> That the final parent class is defined like this:
> {code:title=BeansWrapperConfiguration.java}
> public abstract class BeansWrapperConfiguration<T extends
> BeansWrapperConfiguration> implements Cloneable
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
