0

以前は、次のような 3 つのコンストラクターがありました。

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

しかし、現在はコンストラクターが 1 つしかないため、不便な点があります。なぜ他の 2 つのコンストラクターが削除されたのでしょうか。

2 つのコンストラクターを削除するのは、この種の悪い API 設計ですか?

4

2 に答える 2

2

簡単な答え: IndexWriter コンストラクター戦略の時間の経過に伴う全体的な変化は、主にコンストラクター オプションの増殖を減らし、使用されているオプションをより適切にカプセル化して共有および再利用できるようにすることでした。

より長い回答: 参照している 3 つの引数コンストラクター (ディレクトリ/文字列/ファイル、アナライザー、ブール値) は、2008 年 10 月 11 日にリリースされた Lucene 2.4 で廃止され、Lucene 3.0 (2009 年 11 月 26 日) で削除されました。

結論: これらのコンストラクターが最終的に廃止されるという通知が 1 年間あり、ほぼ 3 年前にリリースされたリリースで削除されました。

古いバージョンではない Lucene へのアップグレードに関心があり、3 つの引数の 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 のドキュメントを見て、現在利用可能なさまざまなオプションのいくつかを検討することをお勧めします。

于 2012-09-18T23:28:03.420 に答える
0

実際には、IndexWriterConfig が登場する前の最後の GA リリース バージョンである Lucene 3.0.3の IndexWriter には、5 つのコンストラクター (3 つではありません)がありました。これは、変更に関する元のチケットです(つまり、IndexWriterConfig と、他のコンストラクターの削除の非推奨)。チケットの上部にあるディスカッションへのリンクは機能しなくなりましたが、Nabble にはそのコピーがあります。

「2つのコンストラクタを削除するのは、この種の悪いAPI設計ですか?」これは、SO FAQ が SO で尋ねるべきではないと述べている自由回答形式の質問です。いずれにせよ、特定の決定を下す際の Lucene 開発者の意図を知りたい場合は、Lucene 開発者に直接、つまり公式の Lucene メーリング リストで質問するか、 Luceneでチケットを開くよりも良い方法はありません。問題追跡システム。

推測するなら、いくつかの可能性があります：

  • 彼らは問題を見落としているか、(重要性は主観的なものであるため、あなたのようなユーザーに比べて) コンストラクターを保持することの重要性を過小評価している可能性があります。
  • コンストラクターを保持すると、メンテナンスのオーバーヘッドが発生します。物事を「クリーン」にしないことに加えて (これも主観的です)、開発者は IndexWriter (削除ポリシーなど) と IndexWriterConfig の両方でデフォルト設定を維持する必要がありました。
  • ユーザーがコードを変更する必要がないようにコンストラクターを維持すると、3.0/4.0 への移行の有用性が制限されます。4.0 には非常に多くの変更が加えられているため、Lucene Core 4.0 のコードを差し込んで、アプリケーションがまだ機能することを期待することはできません。

そして、あなたが私に尋ねたら、いいえ、それは「悪い API 設計」ではないと思います。すべてのメソッド呼び出しが永遠にそのまま維持されると期待するのは不合理です。彼らには下位互換性ポリシーがあり、その一部は必要に応じて非推奨にすることができるため、私は理解していますが、次のメジャーリリースまで物事を削除したり壊したりしません. 最悪の1つ？ポイントリリース間で (バグを修正していなくても) 同等のポリシーや変更動作を持たない他の人気のあるプロジェクトよりもはるかに優れていると思います。

于 2012-10-22T19:44:48.530 に答える