Pourquoi le java.util.Set<V> interface fournissent pas un get(Object o) méthode?

Tandis que la pureté de l'argument de la méthode get(Object) suspect, l'intention sous-jacente n'est pas discutable.

Il existe différentes classe et d'interface familles que légèrement redéfinir equals(Object). Il suffit de regarder pas plus loin que les collections des interfaces. Par exemple, une ArrayList et LinkedList peut être égal; leurs contenus respectifs ont simplement besoin d'être les mêmes et dans le même ordre.

Par conséquent, il y a de très bonnes raisons pour trouver le correspondant élément dans un ensemble. Peut-être une meilleure façon d'indiquer l'intention est d'avoir une méthode comme

public interface Collection<E> extends ... {
  ...
  public E findMatch(Object o) throws UnsupportedOperationException;
  ...
}

Noter que cette API a une valeur plus large que dans un délai Défini.

À la question elle-même, je n'ai pas de théorie pour expliquer pourquoi une telle opération a été omis. Je dirai que le minimal spanning ensemble argument ne tient pas, car de nombreuses opérations définies dans les collections de l'Api sont motivés par des raisons de commodité et d'efficacité.

J'ai eu la même question en java forum il y a des années. Ils m'ont dit que l'Ensemble de l'interface est définie. Il ne peut pas être modifié, car il va casser les implémentations actuelles de l'interface. Ensuite, ils ont commencé à dire des conneries, comme vous le voyez ici: "Set n'a pas besoin de la méthode get" et a commencé à forer moi que la Carte doit toujours être utilisé pour obtenir les éléments d'un ensemble.

Si vous utilisez l'ensemble uniquement pour des opérations mathématiques, comme l'intersection ou l'union, alors peut-être contient() est suffisant. Toutefois, le Jeu est défini dans les collections pour stocker des données. Je l'ai expliqué pour le besoin de get() dans le Jeu en utilisant le modèle de données relationnel.

Dans ce qui suit, une table SQL est comme une classe. Les colonnes de définir les attributs (connu sous le nom des champs en Java) et les enregistrements représentent des instances de la classe. De sorte qu'un objet est un vecteur de champs. Certains champs sont des clés primaires. Ils définissent l'unicité de l'objet. C'est ce que vous faites pour contains() en Java:

class Element {

        public int hashCode() {return sumOfKeyFields()}
        public boolean equals(Object e) {keyField1.equals(e) && keyField2.equals(e) && ..}

Je ne suis pas au courant de la DB à l'intérieur. Mais, vous, indiquez la clé des champs qu'une seule fois, lors de définir une table. Vous venez d'annoter la clé des champs avec @primaire. Vous ne spécifiez pas les touches deuxième temps, lorsque vous ajoutez un enregistrement à la table. Vous ne séparez pas les clés de données, comme vous le faites dans la cartographie. Tables SQL sont des ensembles. Ils ne sont pas les cartes. Pourtant, ils fournissent get() en plus de maintenir l'unicité et contient() vérifier.

Dans "l'Art de la Programmation Informatique", l'introduction de la recherche, D. Knuth dit la même chose:

La plupart de ce chapitre est consacrée à l'étude d'un très simple de recherche
problème: comment trouver les données qui ont été stockées avec un
d'identification.

Vous voyez, les données sont stocker de l'identification. Pas d'identification de pointage de données, mais de données, de l'identification à. Il poursuit:

Par exemple, dans une application numérique, nous pourrions vouloir
trouver f(x), x et un tableau de valeurs de f; en un
non numérique de l'application, nous pourrions trouver de l'anglais
la traduction d'un mot russe.

On dirait qu'il commence à parler de la cartographie. Cependant,

En général, nous supposons qu'un ensemble de N enregistrements ont été conservés,
et le problème est de trouver celui qui convient le mieux. Nous demandons généralement
la N de clés distinctes, de sorte que chaque clé identifie de manière unique son
record. La collection de tous les dossiers est appelé un table ou fichier,
où le mot "table" est généralement utilisé pour indiquer un fichier de petite taille, et
"fichier" est généralement utilisé pour indiquer une grande table. Un gros fichier ou un
groupe de fichiers est souvent appelé un base de données.

Les algorithmes de recherche sont présentés avec un soi-disant argument, K,
et le problème est de trouver le dossier qui a K comme sa clé. Bien que l'
l'objectif de la recherche est de trouver l'information stockée dans l'enregistrement
associé avec K, les algorithmes de ce chapitre généralement ignorer
tout, mais les touches elles-mêmes. Dans la pratique, nous pouvons trouver la
de données associées, une fois que nous avons situé K; par exemple, si K apparaît dans
emplacement TABLE + i, les données associées (ou un pointeur) peut être
dans un endroit TABLEAU + i + 1

Qui est, la recherche localise la clé du dépôt du dossier et il ne devrait pas "la carte" la clé de données. Les deux sont situés dans le même dossier, comme les champs de l'objet java. C'est, de l'algorithme de recherche examine les principaux champs de l'enregistrement, comme il le fait dans le jeu, plutôt que d'une touche de la télécommande, comme il le fait dans la carte.

Nous sont données de N éléments à trier; nous les appelons enregistrements, et
l'ensemble de la collection de N enregistrements sera appelée une fichier. Chaque
enregistrement Rj a une clé Kj, qui régit le processus de tri. Supplémentaires
données, en plus de la clé, est aussi le plus souvent; cela extra "par satellite
l'information" n'a aucun effet sur le tri, sauf qu'il doit être transporté
le long de dans le cadre de chaque enregistrement.

Non plus, je ne vois aucune nécessité de dupliquer les clés dans un supplément de "jeu de clés" dans sa discussion de tri.

... ["The Art of Computer Programming", Chapitre 6, Introduction]

entité est de la collecte ou de l'ensemble de toutes les entités d'un type d'entité
[http://wiki.answers.com/Q/What_is_entity_and_entity_set_in_dbms]
Les objets de la classe unique de partager leurs attributs de classe. De même, faire des enregistrements dans la base de données. Ils partagent les attributs de colonne.

Un cas particulier d'une collection est une étendue de la classe, qui est la
collection de tous les objets appartenant à la classe. Classe extensions permettent
les classes à être traités comme des relations

... ["Système de base de données de Concepts", 6e Édition]

Fondamentalement, classe décrit les attributs communs à toutes ses instances. Une table dans le relationnel fait de même. "Le plus simple de cartographie que vous aurez jamais est une propriété de la cartographie d'un seul attribut à une seule colonne." C'est le cas, je suis en train de parler.

Je suis tellement détaillé sur la preuve de l'analogie (isomorphisme) entre les objets de base de données et les enregistrements, car il y a des gens stupides qui ne l'acceptent pas (pour prouver que leur Ensemble ne doit pas avoir la obtenir méthode)

Que vous voyez dans les replays comment les gens, qui ne comprennent pas cela, dire que Défini à obtenir serait redondant? C'est parce que leur abusé de la carte, qu'ils imposent à utiliser à la place de jeu, introduit de la redondance. Leur appel à mettre(obj.getKey(), obj) stocke deux clés: la clé d'origine dans le cadre de l'objet et une copie de celui-ci dans l'ensemble des clés de la carte. La duplication est la redondance. Elle implique aussi plus de ballonnement dans le code et les déchets de la mémoire consommée lors de l'Exécution. Je ne sais pas à propos de DB internes, mais les principes de bonne conception et de la normalisation de base de données de dire que ce phénomène est une mauvaise idée - il doit y avoir une seule source de vérité. La redondance des moyens que l'incohérence peut arriver: la clé correspond à un objet qui a une clé différente. L'incohérence est une manifestation de la redondance. Edgar F. Codd proposé DB normalisation juste pour se débarrasser de licenciements et leurs déduit des incohérences. Les enseignants sont explicites sur la normalisation: La normalisation ne sera jamais de générer des deux tables avec un one-to-one relation entre eux. Il n'y a pas de raison théorique pour séparer une seule entité comme ça avec certains champs dans un seul enregistrement d'une table et d'autres dans un seul enregistrement d'une autre table

Donc, nous avons 4 arguments, pourquoi utiliser une carte pour la mise en œuvre de l'obtenir dans le jeu est mauvais:

1. la carte est inutile quand on a un ensemble unique d'objets
2. carte introduit de la redondance dans l'Exécution de stockage
3. carte introduit augmentation du code dans la base de données (dans les Collections)
4. à l'aide de la carte contredit le stockage de données, normalisation

Même si vous n'êtes pas au courant de l'ensemble d'enregistrements idée et la normalisation des données, de jouer avec les collections, vous pouvez découvrir cette structure de données et algorithme de vous-même, comme nous, org.eclipse.KeyedHashSet et C++ STL concepteurs n'.

J'ai été banni du forum Sun pour souligner ces idées. Le fanatisme est le seul argument à l'encontre de la raison et de ce monde est dominé par des fanatiques. Ils ne veulent pas voir les concepts et la façon dont les choses peuvent être différentes, améliorées. Ils ne voient que le monde réel et ne peut pas imaginer que la conception de Java Collections peuvent avoir des carences et pourrait être améliorée. Il est dangereux de rappeler la justification de choses à de telles personnes. Ils vous enseignent leur aveuglement et de sanctionner si vous ne respectez pas.

Ajouté Décembre 2013: SICP dit aussi que DB est un jeu avec un détrompeur dossiers plutôt que d'une carte:

Typique de données-système de gestion de la dépense une grande quantité de temps
d'accéder ou de modifier les données dans les dossiers et nécessite donc
une méthode efficace pour l'accès aux dossiers. Ceci est fait par l'identification de
une partie de chaque enregistrement pour servir d'identification de la clé. Maintenant que nous représentons
la base de données comme un ensemble d'enregistrements.

Je ne suis pas sûr si vous êtes à la recherche d'une explication de pourquoi Jeux de se comporter de cette façon, ou pour une solution simple au problème qu'il pose. D'autres réponses traitées avec l'ancien, voici une suggestion de ce dernier.

Vous pouvez effectuer une itération sur l'Ensemble des éléments et de tester chacun d'eux pour l'égalité à l'aide de la méthode equals (). Il est facile à mettre en œuvre et peu enclin à l'erreur. Évidemment, si vous n'êtes pas sûr si l'élément est dans le jeu ou pas, vérifier avec la méthode contains() à l'avance.

Ce n'est pas efficace par rapport à, par exemple, HashSet de la méthode contains (), qui signifie "trouver" la stockées élément, mais ne pas le retourner. Si votre jeux peut contenir de nombreux éléments, il pourrait même être une raison de l'utilisation d'un "plus lourd" solution de contournement, comme l'application de la feuille que vous avez mentionné. Cependant, si c'est important pour vous (et je ne vois l'intérêt d'avoir cette capacité), c'est probablement la peine.

Suffit d'utiliser la solution Map... un TreeSet et un HashSet aussi le faire, car ils sont soutenus par un TreeMap et d'une table de hachage, donc il n'y a pas de peine à le faire (actuellement il doit être un gain minime).

Vous pouvez également étendre votre Jeu préféré pour ajouter la méthode get ().

[]]

Si vous pensez à ce sujet comme un ensemble mathématique, vous pouvez obtenir un moyen de trouver l'objet.

Se croisent avec une collection d'objet contenant uniquement les objets que vous voulez trouver. Si l'intersection n'est pas vide, le seul élément à gauche dans le jeu est celui que vous recherchez.

public <T> T findInSet(T findMe, Set<T> inHere){
   inHere.retainAll(Arrays.asList(findMe));
   if(!inHere.isEmpty){
       return inHere.iterator().next();
   }
   return null;
}

Ses pas l'utilisation la plus efficace de la mémoire, mais de son point de vue fonctionnel que mathématiquement correct.

Je pense que l'attente est égale à vraiment représenter une certaine égalité, et pas simplement que les deux objets ont la même clé primaire, par exemple. Et si equals représenté deux objets égaux, alors un obtenir serait redondante. Les cas d'utilisation que vous souhaitez suggère une Carte, et peut-être une autre valeur pour la clé, quelque chose qui représente une clé primaire, plutôt que l'ensemble de l'objet, puis correctement implémenter equals et hashcode en conséquence.

Object fromSet = set.tailSet(obj).first();

if (! obj.equals(fromSet)) fromSet = null;

est-ce que vous cherchez. Je ne sais pas pourquoi java cache.

J'ai eu le même problème. Je l'ai fixée par la conversion de mon jeu de la Carte, puis de les obtenir à partir de la carte. J'ai utilisé cette méthode:

public Map<MyObject, MyObject> convertSetToMap(Set<MyObject> set)
{
    Map<MyObject, MyObject> myObjectMap = new HashMap<MyObject, MyObject>();

    for(MyObject myObject: set){
        myObjectMap.put(myObject, myObject);
    }
    return myObjectMap
}

Vous pouvez maintenant obtenir des éléments de votre jeu en appelant cette méthode comme ceci:

convertSetToMap(myset).get(myobject);

Vous pouvez remplacer les égaux dans votre classe pour laisser cocher sur seulement certaines propriétés comme Id ou nom.

C'est évidemment une lacune de l'Ensemble de l'API.

Simplement, je veux à la recherche d'un objet dans mon Jeu et de mise à jour de ses biens.

Et je boucle mon (Hash)de mon objet... Soupir...

La raison pour laquelle il n'y a pas de obtenir est simple:

Si vous avez besoin pour obtenir l'objet X à partir de l'ensemble est parce que vous avez besoin de quelque chose à partir de X et que vous n'avez pas l'objet.

Si vous ne disposez pas de l'objet, puis vous avez besoin de quelques moyens (clé) pour le localiser. ..son nom, un certain nombre de ce que jamais. C'est ce que les cartes sont pour la droite.

carte.get( "clé" ) -> X!

Jeux n'ont pas les clés, vous avez besoin de yo les traverser pour obtenir les objets.

Alors, pourquoi ne pas ajouter une pratique get( X ) -> X

Qui n'a aucun sens droite, parce que vous avez X déjà, les puristes diront.

Mais maintenant, regardez comme non puriste, et de voir si vous voulez vraiment ce:

Dire que je fais l'objet Y, qui correspond à l'égal de X, de telle sorte que l'.get(Y)->X. est volia, alors je peux accéder aux données de X que je n'ai avoir des. Disons, par exemple, X est une méthode appelée obtenir drapeau() et je veux la suite de cela.

Maintenant, regardez ce code.

Y

X = map.get( Y );

Donc Y. equals( x ) vrai!

mais..

Y. drapeau() == X. drapeau() = faux. ( N'étaient-ils pas égaux ?)

Donc, vous voyez, si le jeu vous a permis d'obtenir les objets, comme Elle l'est certainement pour briser la base sémantique du signe égal. Plus tard, vous allez vivre avec peu de clones de X tous claming qu'ils sont de la même quand ils ne le sont pas.

Vous avez besoin d'une carte, pour stocker des trucs et utiliser une clé pour le récupérer.

L'interface simple/API donne plus de liberté lors de la mise en œuvre. Par exemple, si Set interface serait réduit simplement à un seul contains() méthode, nous obtenons une définition de jeu typique pour la programmation fonctionnelle - c'est juste un prédicat, pas d'objets sont stockés. C'est également vrai pour java.util.EnumSet - elle ne contient qu'une image bitmap pour chaque valeur possible.

Liste est ordonnée à la structure de données. Donc il suit l'ordre d'insertion. Donc les données que vous mettez sera disponible à la position exacte du temps que vous avez inséré.

List<Integer> list = new ArrayList<>();
list.add(1);
list.add(2);
list.add(3);

list.get(0); //will return value 1

Rappelez-vous cette simple tableau.

Ensemble de l'onu a ordonné la structure de données. Donc, il ne suit pas un ordre. Les données que vous introduisez dans certaine position sera disponible à n'importe quelle position.

Set<Integer> set = new HashSet<>();
set.add(1);
set.add(2);
set.add(3);
//assume it has get method
set.get(0); //what are you expecting this to return. 1?.. 

Mais il sera de retour quelque chose d'autre. Par conséquent, elle n'a pas de sens de créer une méthode obtenir dans le Jeu.

****Remarque**Pour l'explication, j'ai utilisé le type int, cette même chose est applicable pour le type d'Objet également.