Iterable<T>
コレクションをインスタンスフィールドとして持つのではなく、いつ実装することを検討する必要がありますか?メリット/結果は何ですか?
4 に答える
JavaDocはそれをすべて言います:
このインターフェースを実装すると、オブジェクトを「foreach」ステートメントのターゲットにすることができます。
インターフェイスの実装者を見ると、いつ使用するかが明確になります。独自のコレクション(またはユーザーが反復できる「何か」)を作成する場合は、インターフェースを実装するのが理にかなっています。結論として、「シンプルで標準的な」アプリケーションでの私の経験では、独自のアプリケーションを実装することは決してありませんIterable
。
Iterableの実装はカプセル化をサポートします。(通常)クラスのユーザーは、リンクリストとハッシュテーブルのどちらを使用しているか、または何を使用しているかを知る必要はありません。
クラスを使用するコードを変更せずに、実装の詳細を変更できます。たとえば、アイテムの数に応じてコレクションを切り替えたい場合があります。
また、ユーザーが実行できることと実行できないことを制御できます。あなたがあなたのコレクションへの直接アクセスを与えるならば、彼らはあなたの知らないうちにそれを修正するかもしれません、非常に悪い考えです。
可能な限り、より一般的なインターフェースを使用します。Iterable<T>
より一般的であるようList<T>
に、関数のクライアントが反復可能なインターフェイスのみに依存している場合(リストインターフェイスには依存していない場合)、反復可能を優先します。これにより、後で実装を変更してインターフェースを変更する可能性が高くなります。
質問は非常に一般的であるため、同じ精神でこの答えを取ります。
オブジェクト指向設計で一般的で人気のある信条は、実装の詳細のカプセル化と非表示です。したがって、コンテナがクラスの単なる実装の詳細である場合、それはまったく表示されないはずです。
より一般的には、データメンバーを直接公開することを検討している場合は、よく考えてください。うまく設計されたクラスは、おそらくメンバーに物事を渡すだけではいけません。むしろ、クラス自体のセマンティクスを記述する有用なメソッドをクラスに提供する必要があります。それらは順番に内部コンテナを使用するかもしれませんが、コンテナ自体がユーザーに直接向いてはいけません。
最後に、クラス自体に反復可能なセマンティクス(おそらく内部コンテナーを使用して実装する)がある場合は、必ずクラス自体にイテレーターを指定してください。イテレータを使用すると、一般的なアルゴリズムを使用でき、さまざまな設定でクラスを使用できるようにするための優れた方法です。ただし、イテレータが意味的に意味のある値の範囲をトラバースすることを確認してください。メンバーコンテナを掘り下げたり、追加の処理とチェックを行ったりする場合があります。いずれにしても、イテレータは、一部のメンバーコンテナのイテレータだけでなく、自分のものである必要があります。