为什么lucene 4.0为IndexWriter类删除了两个构造函数？

Question

曾经有三个构造函数，例如

IndexWriter(String, Analyzer, boolean)
IndexWriter(String, Analyzer, boolean)
IndexWriter(Directory,Analyzer, boolean)

但是现在只有一个构造函数，这会带来一些不确定性，那么为什么要删除其他两个构造函数呢？

这种糟糕的api设计是否删除了两个构造函数？

Answer 1

简短回答：随着时间的推移，IndexWriter构造函数策略的整体变化主要是为了减少构造函数选项的扩散，并更好地封装所使用的选项，以便可以共享它们。重复使用。

更长的答案：你所指的三个arg构造函数（目录/字符串/文件，分析器，布尔值）在2008年10月11日发布的Lucene 2.4中被弃用，然后在Lucene 3.0中被删除（2009年11月26日）

结论：有一整年的通知，那些构造函数最终会消失，并且在大约3年前发布的版本中被删除了。

如果您有兴趣升级到非古老版本的Lucene，并且您最大的抱怨是您的三个arg IndexWriter构造函数不再存在，那么只需更改看起来像这样的代码......

IndexWriter w = new IndexWriter(dir, analyzer, true);

...所以它看起来像这样......

IndexWriterConfig c = new IndexWriterConfig(Version.LUCENE_36,analyzer).setOpenMode(CREATE_OR_APPEND)
IndexWriter w = new IndexWriter(dir, config);

...但我建议您不要盲目地进行更改，而是实际查看IndexWriterConfig的文档，并考虑现在可用的各种选项。

Answer 2

实际上，Lucene 3.0.3中有5 constructors (not 3) for IndexWriter，这是IndexWriterConfig发布之前的最后一个GA版本。这是original ticket about the change（即IndexWriterConfig和删除其他构造函数的弃用）。票证顶部附近讨论的链接不再有效，但Nabble has a copy of it。

“这种糟糕的api设计是否会删除这两个构造函数？”这是SO FAQ says should not be asked on SO的开放性问题。无论如何，如果你想知道Lucene开发人员做出特定决定的意图，没有比直接询问Lucene开发人员更好的方法，即在official Lucene mailing lists上，或者在Lucene issue-tracking system

如果我推测，这里有一些可能性：

• 他们可能忽略了这个问题或者低估了（相对于像你这样的用户，因为重要性是主观的）保持建设者的重要性。
• 保持构造函数会有维护开销。除了使事情不那么“干净”（这也是主观的）之外，开发人员还需要在IndexWriter（例如删除策略）和IndexWriterConfig中维护默认设置。
• 维护构造函数只是为了让用户不必更改代码对3.0 / 4.0转换的用处有限。因为4.0中有如此多的变化，人们不能指望只是放入Lucene Core 4.0代码并期望它们的应用程序仍能正常工作。

如果你问我，那么不，我不认为这是“糟糕的API设计”。期望他们永远保持每个方法调用完整是不合理的。他们确实有一个向后兼容性策略，我理解其中的一部分，因为他们可以弃用任何想要的东西，但是在下一个主要版本发布之前它们不会删除或破坏。最糟糕的一个？我认为这比其他一些在点发布之间没有类似政策和/或改变行为（即使没有修复错误）的流行项目更好。