Pour implémenter un type itérable ou non? [fermé

Question

Quand devrait-on envisager de mettre en œuvre Iterable<T> Au lieu d'avoir une collection comme champ d'instance? Quels sont les avantages / conséquences?

Answer 1

La mise en œuvre de l'encapsulation des supports de supports. Il n'y a (généralement) pas besoin que les utilisateurs de votre classe sachent si vous utilisez une liste liée ou une table de hachage ou ce que vous avez.

Vous pouvez modifier les détails de l'implémentation sans avoir à modifier un code qui utilise votre classe. Vous souhaitez peut-être basculer entre les collections en fonction du nombre d'éléments, par exemple.

Vous contrôlez également ce que l'utilisateur peut et ne peut pas faire. Si vous donnez un accès direct à votre collection, ils peuvent le modifier à votre insu, une très mauvaise idée.

Answer 2

La Javadoc dit tout:

La mise en œuvre de cette interface permet à un objet d'être la cible de l'instruction "foreach".

Regardez les implémentateurs de l'interface et il devient clair quand l'utiliser. Si vous construisez votre posséder Collection (ou «quelque chose» qu'un utilisateur devrait être capable d'itérer), il est logique d'implémenter l'interface. Pour conclure, d'après mon expérience dans une application «simple et standard», vous n'implémerez jamais la vôtre Iterable.

Answer 3

J'utiliserais une interface plus générale dans la mesure du possible. Comme Iterable<T> est plus général que List<T>, si les clients de la fonction ne dépendent que l'interface itérable (et non sur l'interface de liste), je préférerais itérable. Cela permet une forte possibilité de modifier plus tard l'implémentation qui modifierait l'interface.

Answer 4

La question est très générale, alors prenez cette réponse dans le même esprit.

Un principe commun et populaire dans le design orienté objet est encapsulation et Cacher les détails de l'implémentation. Donc, si votre conteneur est un simple détail d'implémentation de la classe, il ne doit pas du tout être visible.

Plus généralement, si vous envisagez d'exposer directement les membres de données, réfléchissez à deux fois. Une classe bien conçue ne devrait probablement pas simplement remettre les choses aux membres. Vous voulez plutôt donner à la classe des méthodes utiles qui décrivent la sémantique de la classe. Ceux-ci peuvent à leur tour utiliser le conteneur interne, mais le conteneur lui-même ne doit pas être directement confronté à l'utilisateur.

Enfin, si votre classe elle-même a une sémantique itérable (que vous metterez probablement en œuvre avec un conteneur interne), alors donnez par tous les itérateurs lui-même. Les itérateurs vous permettent d'utiliser des algorithmes génériques et sont un excellent moyen de rendre votre classe utilisable dans une grande variété de paramètres. Cependant, assurez-vous que les itérateurs traversent une gamme de valeurs sémantiquement significatives. Ils peuvent creuser directement dans un conteneur membre, ou ils peuvent effectuer un traitement et une vérification supplémentaires - de toute façon, les itérateurs devraient être le tiens, pas seulement ceux d'un conteneur membre.