On 10/3/09 4:18 AM, Earwin Burrfoot wrote:
Builder pattern allows you to switch concrete implementations as you
please, taking parameters into account or not.
Besides that there's no real difference. I prefer builder, but that's just me :)
Why can't you do that with a factory that takes a config object as
parameter? Seems very similar to me... the only difference is syntax,
isn't it?
And if you have setter methods on the config object or methods that
return "this" that you can concatenate is just personal preference,
right? Personally I prefer the setter methods for our usecase, simply
because there are so many config options. Maybe you don't want to set
them all in the same places in your app code? E.g. in our app we have a
method like applyIWConfig(IndexWriter) that, as the name says, applies
all settings we have in a customizable config file. However, some IW
settings are not customizable, and applied somewhere else in our code. I
think with the concatenation pattern this would look less intuitive than
with good old setter methods. You'd have to change
applyIWConfig(IndexWriter.Builder) to return IW.Builder and do the
concatenation both in the method and in the caller.
But, like Mark said, maybe this is just my personal preference and for
others not compelling arguments. Or maybe I'm missing some other
advantage of the builder pattern? I haven't used/implemented it myself
very much yet...
Michael
Thats just me though.
Michael McCandless wrote:
OK, I agree, using the builder approach looks compelling!
Though what about required settings? EG IW's builder must have
Directory, Analyzer. Would we pass these as up-front args to the
initial builder?
And shouldn't we still specify the version up-front so we can improve
defaults over time without breaking back-compat? (Else, how can
we change defaults?)
EG:
IndexWriter.builder(Version.29, dir, analyzer)
.setRAMBufferSizeMB(128)
.setUseCompoundFile(false)
...
.create()
?
Mike
On Fri, Oct 2, 2009 at 7:45 PM, Earwin Burrfoot<ear...@gmail.com> wrote:
On Sat, Oct 3, 2009 at 03:29, Uwe Schindler<u...@thetaphi.de> wrote:
It is also probably a good idea to move various settings methods from
IW to that builder and have IW immutable in regards to configuration.
I'm speaking of the likes of setWriteLockTimeout, setRAMBufferSizeMB,
setMergePolicy, setMergeScheduler, setSimilarity.
IndexWriter.Builder iwb = IndexWriter.builder().
writeLockTimeout(0).
RAMBufferSize(config.indexationBufferMB).
maxBufferedDocs(...).
similarity(...).
analyzer(...);
... = iwb.build(dir1);
... = iwb.build(dir2);
A happy user of google-collections API :-) These builders are really cool!
I feel myself caught in the act.
There is still a couple of things bothering me.
1. Introducing a builder, we'll have a whole heap of deprecated
constructors that will hang there for eternity. And then users will
scream in frustration - This class has 14(!) constructors and all of
them are deprecated! How on earth am I supposed to create this thing?
2. If someone creates IW with some reflectish javabeanish tools - he's
busted. Not that I'm feeling compassionate for such a person.
I like Earwin's version more. A builder is very flexible, because you can
concat all your properties (like StringBuilder works with its append method
returning itself) and create the instance at the end.
Besides (arguably) cleaner syntax, the lack of which is (arguably) a
curse of many Java libraries,
it also allows us to return a different concrete implementation of IW
without breaking back-compat,
and also to choose this concrete implementation based on settings
provided. If we feel like doing it at some point.
--
Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
