0

hasNext と Next が次のように機能する場合、非常に良い方法のように思えます。

boolean hasNextCalled = false;

boolean hasNext() {
  hasNextCalled  = true
}

next() {
  assert hasNextCalled
}

このようにして、NoSuchElementException() が発生するようなケースに遭遇することはありません。hasNext() 呼び出しが強制されない実用的な理由はありますか?

4

6 に答える 6

9

どのようなメリットがありますか? NoSuchElementExceptionaを に置き換えるだけAssertionErrorで、わずかなオーバーヘッドが発生します。また、Iteratorはインターフェイスであるため、これを一度実装することはできません。のすべての実装で使用する必要がありIteratorます。hasNextさらに、ドキュメントでは、 を呼び出す前に呼び出す必要がないnextため、提案は現在の契約を破ることになります。このような変更は、NoSuchElementException. 最後に、製品コードではアサーションをオフにすることができるため、引き続きこのNoSuchElementExceptionメカニズムが必要になります。

于 2013-08-15T22:14:43.813 に答える
3

NoSuchElementExceptionランタイム例外であり、プログラマーのエラーを反映しています...あなたのアプローチとまったく同じです。hasNext()たとえば、事前にコレクションのサイズを知っていて、何回呼び出すことができるかを知っている場合など、呼び出す必要がないため、呼び出すことは必須ではありませんnext()。

ポイントは、プログラマーのエラーを報告する 1 つの方法を交換しているということです...プログラマーのエラーを報告する別の方法は、いくつかの有用なアプローチを無効にする可能性があります。

于 2013-08-15T22:15:12.140 に答える
1

要素が残っていることはすでにわかっているかもしれません。たとえば、同じサイズの 2 つのリストをロックステップで繰り返し処理しているhasNext場合、両方をチェックするために 1 つのイテレータを呼び出すだけで済みます。また、assert呼び出しを行っても、特にアサーションがオフの場合は、hasNext実際には誰も呼び出しnextを防ぐことはできません。hasNext

于 2013-08-15T22:18:56.880 に答える
0

私の2セント。ここで、API はクライアントの使用状況を想定し、それを強制します。私は常に1つの結果しか返さないと確信しているとしましょうhasNext().next()

于 2013-08-15T22:15:54.053 に答える