> >> The builder pattern and the config argument to a factory both have the > >> advantage that you can limit changes after creating an object. Some > >> things are just bad to change in mid-stream. The config argument is > >> nice in that you can pass it around to different stake holders, but > >> the builder can be used a bit like that as well. > >> > > Yeah that argument has been made. But I've *never* seen it as an issue. > > Just seems like a solution looking for a problem. I can see how it's > > cleaner, not missing that point. But still doesn't make me like it much. > > > > > Yeah personally this wasn't a problem for me either. I do like the > cleanliness though. Also, I'd very much prefer a config object over > multiple constructors (with the need to deprecate/add with every > change), as I proposed originally in this thread. > > I still don't see an advantage of the builder pattern over the config > object + factory pattern - and I'm not even sure if we really need a > factory; IMO passing a config object into a single constructor would be > sufficient for IW.
For IR the factory would be ok. In my opinion you could also combine both patterns: - Each setter in the config object returns itself, so you have the builder pattern, but you could also use it in classical setter way (this only works if the builder pattern always returns itself not a new builder object) - The builder factory .build() just delegates to the ctor/static factory in IR/IW and passes itself to it). So you have both possibilities: IndexReader reader = new IndexReader.Config(dir).setReadOnly(true) .setTermInfosIndexDivisor(foo).build(); is equal to: IndexReader.Config config = IndexReader.Config(dir); config.setReadOnly(true); config.setTermInfosIndexDivisor(foo); IndexReader reader = IndexReader.create(config); Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
