Selon la règle numéro 4 de Object Calisthenics de Jeff Bay (RTF) dans The ThoughtWorks Anthology, il est recommandé de " Utiliser des collections de première classe ".
Règle 4: Collections de première classe
L'application de cette règle est simple: toute classe qui contient une collection ne doit contenir aucune autre variable membre. Chaque collection est enveloppée dans sa propre classe, donc maintenant les comportements liés à la collection ont une maison. Vous pouvez constater que les filtres font partie de cette nouvelle classe. De plus, votre nouvelle classe peut gérer des activités telles que la jonction de deux groupes ou l'application d'une règle à chaque élément du groupe.
Ce que je pouvais comprendre de cela était que nous devrions utiliser une classe distincte enveloppant la collection et avec des méthodes pour ajouter, supprimer, modifier les données de cette collection.
et nous en avons besoin pour être sûrs du type de données qui entre dans la collection et de ce qui en sort.
Dans le cas où nous utilisons une collection générique (dans les langues où elle est applicable), devons-nous suivre cette règle?
Si je manque une signification importante, veuillez clarifier.
la source
Réponses:
La sécurité des types est une raison très mineure d'utiliser des collections de première classe. Depuis votre lien:
L'idée ici est que si vous vous trouvez à rechercher, filtrer, valider ou quoi que ce soit au-delà d'ajouter / supprimer / itérer la sémantique d'une collection, le code vous demande de la mettre dans sa propre classe. Si vous devez mettre à jour une seule valeur (après une recherche), cela va probablement dans la classe de collection.
Le raisonnement est assez simple, les collections ont tendance à se faire circuler. Bientôt, 4 classes différentes ont leur propre
SearchByID()méthode. Ou vous obtenez des valeurs de retour commeMap<Integer, String>avec le contexte de ce qui est stocké dans cette carte retiré. Une collection de première classe est une solution simple qui coûte un seul fichier source. En pratique, une fois ceux-ci en place (ils sont également très faciles à écrire pour les tests unitaires), tout changement concernant la collection est facile à gérer, comme quand ilSearchByIDfaut prendre un GUID au lieu d'un int.la source
Cela fait bien plus que garantir le type des objets stockés dans les collections, il garantit également tous les invariants de collection.
Les arbres (rouge-noir, AVL, etc.) sont sensibles à l'ordre et leur comportement dépend du rééquilibrage, le cas échéant. Les performances de la table de hachage dépendront également du ré-hachage approprié. Voulez-vous vous rappeler de vérifier le facteur de charge à chaque fois que vous insérez dans une carte de hachage?
FWIW, le texte est assez clair à ce sujet (et je vais éditer le tout dans votre question, donc personne d'autre n'a besoin de télécharger ce RTF):
Rien à voir avec les types (ou donc les génériques), tout à voir avec l'association du comportement de la collection à ses données.
la source
La réponse simple est "Non" si vous utilisez un langage prenant en charge les génériques. Parce qu'il n'est pas nécessaire de vérifier le type car la fonctionnalité de langage elle-même fait un très bon travail à ce sujet (d'après mon expérience des génériques Java).
Mais si vous avez une situation où vous souhaitez personnaliser la structure de données donnée à partir du langage, vous pouvez créer une classe wrapper autour de la structure de données d'origine et exposer vos propres API et toujours utiliser l'implémentation sous-jacente de la structure de données d'origine.
la source