[
https://issues.apache.org/jira/browse/SOLR-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15170749#comment-15170749
]
Jason Gerlowski commented on SOLR-8097:
---------------------------------------
So, looking close at these builder classes, I'm not sure that either an
abstract-class, or an interface approach will allow these methods to be shared
the way we want.
In a nutshell, the problem is that each builder type returns itself, so that
calls can be chained. Setters inherited from an abstract-class/interface
return the type of that abstract interface, which only has a small subset of
the methods of the implementation. This really limits how calls can be chained.
The explanation above seems a little, well, abstract when I re-read it, so
maybe an example will clarify what I'm trying to say. Consider:
{code}
abstract class FooBasedBuilder {
public FooBasedBuilder withFoo(Foo foo) { ... return this;}
public abstract Bar build();
}
class BarBuilder extends FooBasedBuilder {
public BarBuilder withBoo(Boo boo) { ... return this; }
public Bar build() {...}
}
// WORKS!
new BarBuilder()
.withBoo(...) //returns BarBuilder
.withFoo(...) // BarBuilder has a withFoo() method, so this works.
.build()
// ERROR!
new BarBuilder()
.withFoo(...) // returns FooBuilder reference
.withBoo(...) // FooBuilder type doesn't know about withBar(), so this is
a compilation error!
{code}
As the examples above show, with the abstract-class-for-code-sharing design,
the order that setters are called in matters. Once a parent class method is
called, subclass methods can't be chained on.
Maybe there's a way around this, but I haven't been able to find one after
spending an hour or so racking my brains about it. With this in mind, if no
one can find an alternative, I'm going to go back to removing the code-sharing
portion of this patch, as much as that sucks.
> Implement a builder pattern for constructing a Solrj client
> -----------------------------------------------------------
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Affects Versions: master
> Reporter: Hrishikesh Gadre
> Assignee: Anshum Gupta
> Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors
> as follows,
> public CloudSolrClient(String zkHost)
> public CloudSolrClient(String zkHost, HttpClient httpClient)
> public CloudSolrClient(Collection<String> zkHosts, String chroot)
> public CloudSolrClient(Collection<String> zkHosts, String chroot, HttpClient
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient
> httpClient)
> It is kind of problematic while introducing an additional parameters (since
> we need to introduce additional constructors). Instead it will be helpful to
> provide SolrClient Builder which can provide either default values or support
> overriding specific parameter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
