¿Por qué la interfaz java.util.Set <V> no proporciona un método get (Object o)?

Question

Entiendo que solo una instancia de cualquier objeto según .equals() está permitida en un conjunto y que no debería "necesitar" obtener un objeto del conjunto si ya tiene un objeto equivalente, pero aún así desea tener un método .get() que devuelva la instancia real del objeto en el conjunto (o nulo) dado un objeto equivalente como parámetro.

¿Alguna idea/teoría de por qué fue diseñada de esta manera?

Normalmente tengo que hackear esto utilizando un Mapa y haciendo que la clave y el valor sean iguales o algo así.

EDIT: No creo que la gente entienda mi pregunta hasta ahora. Quiero la instancia de objeto exacta que ya está en el conjunto, no una instancia de objeto posiblemente diferente donde .equals() devuelve verdadero.

En cuanto a por qué me gustaría este comportamiento, normalmente .equals() no tiene en cuenta todas las propiedades del objeto. Deseo proporcionar un objeto de búsqueda simulado y recuperar la instancia del objeto real en el Conjunto.

Answer 1

Si bien el argumento de pureza hace que el método get(Object) sea sospechoso, el intento subyacente no es discutible.

Hay varias familias de clase e interfaz que redefinen ligeramente equals(Object). Uno no necesita mirar más allá de las interfaces de colecciones. Por ejemplo, una ArrayList y una LinkedList pueden ser iguales; sus respectivos contenidos simplemente necesitan ser los mismos y en el mismo orden.

En consecuencia, hay muy buenas razones para encontrar el elemento correspondiente en un conjunto. Tal vez una forma más clara de lo que indica la intención es tener un método como

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

Tenga en cuenta que esta API tiene un valor más amplio que dentro de Set.

En cuanto a la pregunta en sí, no tengo ninguna teoría sobre por qué se omitió tal operación. Diré que el argumento del conjunto mínimo de expansión no es válido, porque muchas operaciones definidas en las API de colecciones están motivadas por la conveniencia y la eficiencia.

Answer 2

Bueno, si ya has "sacado" la cosa del set, no necesitas obtenerla, ¿o sí? ;-)

Su enfoque de utilizar un mapa es Lo correcto, creo. Parece que estás tratando de "canonicalizar" objetos a través de su método equals(), que siempre he logrado usando un Mapa como tu sugieres.

Answer 3

Creo que ha respondido a su propia pregunta: es redundante.

El conjunto proporciona el conjunto # contiene (Objeto o) que proporciona la prueba de identidad equivalente del Set # get deseado (Objeto o) y devuelve un valor booleano, como cabría esperar.

Answer 4

El problema es: Set no es para "obtener" objetos, es para agregar y probar la presencia. Entiendo lo que está buscando, tuve una situación similar y terminé usando un mapa del mismo objeto en clave y valor.

EDIT: Solo para aclarar: http://en.wikipedia.org/wiki/Set_(abstract_data_type)

Answer 5

"Quiero que la instancia de objeto exacto que ya está en el conjunto, no una instancia de objeto posiblemente diferente donde .equals() devuelve verdadero."

Esto no tiene sentido. Digamos que haces:

Set<Foo> s = new Set<Foo>(); 
s.Add(new Foo(...)); 
... 
Foo newFoo = ...; 

Ahora hacemos:

s.contains(newFoo) 

Si quieres que eso sólo sería cierto si un objeto en el conjunto es == newFoo, implementar equals y hashCode de Foo con la identidad del objeto. O bien, si está tratando de asignar múltiples objetos iguales a un original canónico, entonces un Mapa puede ser la elección correcta.

Answer 6

Creo que la expectativa es que los iguales representan verdaderamente cierta igualdad, no simplemente que los dos objetos tienen la misma clave principal, por ejemplo. Y si equals representa dos objetos realmente iguales, entonces un get sería redundante. El caso de uso que desee sugiere un Mapa, y tal vez un valor diferente para la clave, algo que representa una clave principal, en lugar de todo el objeto, y luego implemente equals y hashcode en consecuencia.

Answer 7

No estoy seguro de si está buscando una explicación de por qué los Sets se comportan de esta manera, o para una solución simple al problema que plantea. Otras respuestas se refieren a la primera, así que aquí hay una sugerencia para la última.

Puede iterar sobre los elementos del conjunto y probar cada uno de ellos para la igualdad utilizando el método equals(). Es fácil de implementar y difícilmente propenso a errores. Obviamente, si no está seguro de si el elemento está en el conjunto o no, verifique con anterioridad el método contains().

Esto no es eficiente en comparación con, por ejemplo, el método contains() de HashSet, que "busca" el elemento almacenado, pero no lo devolverá. Si sus conjuntos pueden contener muchos elementos, podría ser una razón para usar una solución "más pesada" como la implementación del mapa que mencionó. Sin embargo, si es tan importante para ti (y veo el beneficio de tener esta habilidad), probablemente valga la pena.

Answer 8

Functional Java tiene una implementación de un conjunto persistente (respaldado por un árbol rojo/negro) que de manera incidental incluye un método split que parece hacer algo de lo que usted desea. Devuelve un triplete de:

1. Conjunto de todos los elementos que aparecen antes del objeto encontrado.
2. Un objeto de tipo Option que está vacío o contiene el objeto encontrado si existe en el conjunto.
3. Conjunto de todos los elementos que aparecen después del objeto encontrado.

deberías hacer algo como esto:

MyElementType found = hayStack.split(needle)._2().orSome(hay); 

Answer 9

por lo que entiendo que es posible que tenga dos objetos iguales pero no son la misma instancia.

Tal como

Integer a = new Integer(3); 
Integer b = new Integer(3); 

En que a.equals el caso (b), ya que se refieren al mismo valor intrínseco sino una! = B, ya que son dos objetos diferentes.

Existen otras implementaciones de Conjunto, como IdentitySet, que hacen una comparación diferente entre los elementos.

Sin embargo, creo que está intentando aplicar una filosofía diferente a Java. Si sus objetos son iguales (a.equals (b)) aunque a y b tienen un estado o significado diferente, aquí hay algo mal. Es posible que desee dividir esa clase en dos o más clases semánticas que implementen una interfaz común, o quizás reconsidere .equals y .hashCode.

Si tiene el Effective Java de Joshua Bloch, eche un vistazo a los capítulos llamados "Obedezca el contrato general cuando se reemplaza por igual" y "Minimiza la mutabilidad".

Answer 10

Simplemente use la solución Map ... un TreeSet y un HashSet también lo hacen dado que están respaldados por un TreeMap y un HashMap, por lo que no hay ninguna penalización al hacerlo (en realidad debería ser una ganancia mínima).

También puede extender su conjunto favorito para agregar el método get().

[]]

Answer 11

creo que su única solución, dado alguna implementación Conjunto, es iterar sobre sus elementos para encontrar uno que sea igual a igual() - entonces usted tiene el objeto real en el conjunto que hacía juego.

K target = ...; 
Set<K> set = ...; 
for (K element : set) { 
    if (target.equals(element)) { 
    return element; 
    } 
} 

Answer 12

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

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

hace lo que busca. No sé por qué java lo oculta.

Answer 13

Si lo considera un conjunto matemático, puede encontrar una forma de encontrar el objeto.
Intersecta el conjunto con una colección de objetos que solo contiene el objeto que deseas buscar. Si la intersección no está vacía, el único elemento que queda en el conjunto es el que estaba buscando.

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

No es el uso más eficiente de la memoria, pero es funcional y matemáticamente correcto.

Answer 14

Digamos que tengo un usuario POJO con ID y nombre. ID mantiene el contrato entre iguales y hashcode. nombre no es parte de la igualdad de objetos. Quiero actualizar el nombre del usuario basado en la entrada de alguna parte, digamos, UI.

Como el conjunto java no proporciona el método get, necesito iterar sobre el conjunto en mi código y actualizar el nombre cuando encuentro el objeto igual (es decir, cuando el ID coincide).

Si tiene el método get, este código podría haberse acortado.

Java ahora viene con todo tipo de cosas estúpidas como javadb y mejorado para loop, no entiendo por qué en este caso particular están siendo puristas.

Answer 15

Tuve la misma pregunta en el foro de Java hace años. Me dijeron que la interfaz Set está definida. No se puede cambiar porque romperá las implementaciones actuales de la interfaz Set. Luego, comenzaron a reclamar mierda, como veis aquí: "Set no necesita el método get" y comenzó a taladrarme que siempre se debe usar Map para obtener elementos de un conjunto.

Si usa el conjunto solo para operaciones matemáticas, como intersección o unión, entonces puede contener() es suficiente. Sin embargo, Set se define en colecciones para almacenar datos.Expliqué por necesidad get() en Set usando el modelo de datos relacionales.

En lo que sigue, una tabla SQL es como una clase. Las columnas definen atributos (conocidos como campos en Java) y los registros representan instancias de la clase. De modo que un objeto es un vector de campos. Algunos de los campos son claves primarias. Ellos definen la singularidad del objeto. Esto es lo que haces para contains() en Java:

class Element { 

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

No estoy al tanto de los componentes internos DB. Pero, especifica campos clave solo una vez, cuando define una tabla. Simplemente anota los campos clave con @primary. No especifica las claves por segunda vez, cuando agrega un registro a la tabla. No separa las claves de los datos, como lo hace en el mapeo. Las tablas SQL son conjuntos. No son mapas. Sin embargo, proporcionan get() además de mantener la exclusividad y contiene() verificación.

En "Art of Computer Programming", la introducción de la búsqueda, D. Knuth dice lo mismo:

La mayor parte de este capítulo se dedica al estudio de una manera muy simple problema de búsqueda : cómo encontrar el datos que se almacenaron con una identificación dada .

Verá, los datos se almacenan con identificación. No hay identificación que apunte a datos, pero datos con identificación. Continúa:

Por ejemplo, en una aplicación numérica puede ser que deseemos para encontrar f (x), x dado y una tabla con los valores de f; en una aplicación no numérica , es posible que deseemos encontrar la traducción al inglés de una palabra rusa determinada.

Parece que comienza a hablar sobre el mapeo. Sin embargo,

En general, vamos a suponer que un conjunto de N registros se ha almacenado, y el problema es localizar el apropiado. Generalmente requerimos las N teclas para ser distintas, de modo que cada clave identifica de forma única su registro . La colección de todos los registros se llama tabla o archivo, donde la palabra "tabla" se usa generalmente para indicar un archivo pequeño, y "archivo" se usa generalmente para indicar una tabla grande. Un archivo grande o un grupo de archivos se denomina con frecuencia una base de datos .

Los algoritmos para buscar se presentan con el llamado argumento, K, y el problema es encontrar qué registro tiene K como su clave. Aunque el objetivo de de búsqueda es encontrar la información almacenada en el registro asociado con K, los algoritmos en este capítulo generalmente ignoran todo menos las claves mismas. En la práctica, podemos encontrar los datos asociados una vez que hemos localizado K; por ejemplo, si K aparece en ubicación TABLA + i, los datos asociados (o un puntero a ella) podría ser en lugar TABLA + i + 1

Es decir, la búsqueda localiza la clave presentada de la grabar y no debe "mapear" la clave de los datos.Ambos se encuentran en el mismo registro, como los archivos de objeto java. Es decir, el algoritmo de búsqueda examina los campos clave del registro, como lo hace en el conjunto, en lugar de una clave remota, como lo hace en el mapa.

Nos dan N artículos para ser ordenados; los llamaremos registros y toda la colección de N registros se llamará archivo. Cada registro tiene una clave Kj, que rige el proceso de clasificación. Datos adicionales , además de la clave, también suelen estar presentes; este "satélite adicional información" no tiene ningún efecto en la clasificación, excepto que debe llevarse junto con cada registro.

Ni, no veo la necesidad de duplicar las claves en un "juego de llaves" adicional en su discusión sobre la clasificación.

... [ "The Art of Computer Programming", Capítulo 6, Introducción]

conjunto de entidades es una colección o conjunto de todas las entidades de una entidad en particular de tipo [http: // wiki. answers.com/Q/What_is_entity_and_entity_set_in_dbms] Los objetos de una clase comparten sus atributos de clase. Del mismo modo, haz registros en DB. Comparten atributos de columna.

Un caso especial de una colección es una extensión de clase, que es la colección de todos los objetos que pertenecen a la clase. extensiones de clase permiten clases para ser tratados como las relaciones

... [ "Fundamentos de bases de datos", sexta edición]

Básicamente, clase describe los atributos comunes a todas sus instancias. Una tabla en DB relacional hace lo mismo. "The easiest mapping you will ever have is a property mapping of a single attribute to a single column." Este es el caso del que estoy hablando.

estoy muy prolijo en demostrar la analogía (isomorfismo) entre los objetos y los registros de base de datos porque hay gente estúpida que no aceptan que (para demostrar que su conjunto no debe tener la obtener método)

¿Ves en repeticiones cómo las personas, que no entienden esto, dicen que Set with get sería redundante? Es porque su mapa abusado, que imponen usar en lugar del conjunto, introduce la redundancia. Su llamada a put (obj.getKey(), obj) almacena dos claves: la original como parte del objeto y una copia de la misma en el conjunto de teclas del mapa. La duplicación es la redundancia. También implica más hinchazón en el código y desperdicia memoria consumida en Runtime. No sé acerca de las partes internas de DB, pero los principios de buen diseño y normalización de la base de datos dicen que esa duplicación es mala idea: there must be only one source of truth. La redundancia significa que puede haber inconsistencia: la clave se asigna a un objeto que tiene una clave diferente. La inconsistencia es una manifestación de redundancia. Edgar F. Codd proposed DB normalization solo para deshacerse de las redundancias y sus incoherencias inferidas.Los maestros son explícitos en la normalización: Normalization will never generate two tables with a one-to-one relationship between them. There is no theoretical reason to separate a single entity like this with some fields in a single record of one table and others in a single record of another table

Por lo tanto, tenemos 4 argumentos, por qué usar un mapa para la implementación de ponerse en juego es malo:

1. el mapa no es necesaria cuando tenemos un conjunto de objetos únicos
2. mapa introduce redundancia en el almacenamiento de tiempo de ejecución
3. mapa presenta hinchazón de código en la base de datos (en las colecciones)
4. en el mapa contradice la normalización de almacenamiento de datos

Incluso si no conoce la idea de conjunto de registros y la normalización de datos, jugando con colecciones, puede descubrir esta estructura de datos y algoritmo usted mismo, como lo hicimos nosotros, org.eclipse.KeyedHashSet y C++ STL designers.

Fui excluido del foro de Sun por señalar estas ideas. El fanatismo es el único argumento en contra de la razón y este mundo está dominado por fanáticos. No quieren ver conceptos y cómo las cosas pueden ser diferentes/mejoradas. Ven solo el mundo real y no pueden imaginar que el diseño de las Colecciones Java pueda tener deficiencias y pueda mejorarse. Es peligroso recordar cosas lógicas a tales personas. Te enseñan su ceguera y castigan si no obedeces.

añadido Dec 2013: SICP also says that DB is a set with keyed records rather than a map:

Un típico sistema de gestión de datos gasta una gran cantidad de tiempo acceder o modificar los datos en los registros y por lo tanto requiere un método eficiente para acceder a los registros. Esto se hace identificando como parte de cada registro para que sirva como clave de identificación. Ahora representamos la base de datos como un conjunto de registros.

Answer 16

Tuve el mismo problema. Lo arreglé convirtiendo mi conjunto en un Mapa, y luego obteniéndolos del mapa. He utilizado este método:

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 
} 

Ahora usted puede conseguir elementos de su conjunto llamando a este método como este:

convertSetToMap(myset).get(myobject); 

Puede anular los iguales en su clase para dejar que se compruebe en sólo un cierto propiedades como Id o nombre.

Answer 17

si ha hecho una solicitud para esto en el desfile de errores de Java, listela aquí y podemos votarla. Creo que al menos los java.util.Collections clase de conveniencia que sólo se necesita un conjunto y un objeto y se pone en práctica algo así como

searchSet(Set ss, Object searchFor){ 

     Iterator it = ss.iterator(); 
     while(it.hasNext()){ 
      Object s = it.next(); 
      if(s != null && s.equals(searchFor)){ 
       return s; 
      } 
     } 

Answer 18

Obviamente, esto es un defecto de la API Set.

Simplemente, quiero buscar un objeto en mi conjunto y actualizar su propiedad.

y tengo que recorrer mi (Hash) Ajuste para llegar a mi objetivo ... suspiro ...

Answer 19

Estoy de acuerdo que me gustaría ver Set implementaciones proporcionan un método get().

Como una opción, en el caso donde sus objetos implementen (o puedan implementar) java.lang.Comparable, puede usar un TreeSet. A continuación, la función de tipo get() puede ser obtenida llamando techo() o baja(), seguido de un cheque por el resultado que es no nulo e igual a la del objeto de comparación, tales como:

TreeSet myTreeSet<MyObject> = new TreeSet(); 
: 
: 

// Equivalent of a get() and a null-check, except for the incorrect value sitting in 
// returnedMyObject in the not-equal case. 
MyObject returnedMyObject = myTreeSet.ceiling(comparisonMyObject); 

if ((null != returnedMyObject) && returnedMyObject.equals(comparisonMyObject)) { 
: 
: 
} 

Answer 20

La razón por qué no hay get es simple:

Si necesita obtener el objeto X del conjunto es porque necesita algo de X y no tiene el objeto.

Si no tiene el objeto, entonces necesita algún medio (clave) para localizarlo. .. su nombre, un número que siempre. Eso es lo que los mapas son para la derecha.

map.get ("clave") -> X!

Los juegos no tienen llaves, necesitas atravesarlas para obtener los objetos.

Así que, por qué no añadir un encuentro práctico (X) -> X

que no tiene sentido correcto, porque hay que X ya, purista dirá.

Pero ahora lo veo como no purista, y ver si realmente quiere esto:

Di hago objeto Y, cosa que coincide con los iguales de X, de manera que set.get (Y) -> X. Volia, entonces puedo acceder a los datos de X que no tenía. Digamos, por ejemplo, X tiene un método llamado get flag() y quiero el resultado de eso.

Ahora mira este código.

Y

X = map.get (Y);

So Y.equals (x) true!

pero ..

Y.flag() == X.flag() = false. (¿No eran iguales?)

Así que, ves, si el conjunto te permitía obtener los objetos así Seguramente es romper la semántica básica de los iguales. Más tarde vas a vivir con pequeños clones de X, todos clamando que son lo mismo cuando no lo son.

Necesita un mapa, para almacenar cosas y usar una tecla para recuperarlo.

Answer 21

Entiendo que solo una instancia de cualquier objeto según .equals() está permitida en un conjunto y que no debería "necesitar" obtener un objeto del conjunto si ya tiene un objeto equivalente, pero Todavía me gustaría tener un método .get() que devuelva la instancia real del objeto en el conjunto (o nulo) dado un objeto equivalente como parámetro.

Answer 22

La interfaz/API simple proporciona más libertad durante la implementación. Por ejemplo, si la interfaz Set se reduce solo al método , obtenemos una definición de conjunto típica para la programación funcional: es solo un predicado, no se almacenan realmente objetos. También es cierto para java.util.EnumSet: contiene solo un mapa de bits para cada valor posible.

Answer 23

Es solo una opinión. Creo que debemos entender que tenemos varias clases de Java sin campos/propiedades, es decir, solo métodos.En ese caso, los iguales no se pueden medir comparando la función, uno de ellos es requestHandlers. Vea el ejemplo a continuación de una aplicación JAX-RS. En este contexto, SET tiene más sentido que cualquier estructura de datos.

@ApplicationPath("/") 
public class GlobalEventCollectorApplication extends Application { 
    @Override 
    public Set<Class<?>> getClasses() { 
     Set<Class<?>> classes = new HashSet<Class<?>>(); 
     classes.add(EventReceiverService.class); 
     classes.add(VirtualNetworkEventSerializer.class); 
     return classes; 
    } 
} 

Para responder a su pregunta, si se tiene un objeto de poco empleado (es decir, sólo EMPID, que se utiliza en iguales método para determinar la singularidad), y si usted desea conseguir un objeto profunda al hacer una búsqueda en conjunto, SET no es la estructura de datos, ya que su propósito es diferente.

Answer 24

La lista está ordenada estructura de datos. Entonces sigue el orden de inserción. Por lo tanto, los datos que ingrese estarán disponibles en la posición exacta a la hora que insertó.

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

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

Recuerde esto tan simple matriz.

El conjunto es una estructura de datos no ordenados. Entonces no sigue ningún orden. Los datos que inserte en determinada posición estarán disponibles en cualquier posición.

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?.. 

Pero devolverá algo más. Por lo tanto, no tiene sentido crear el método get en Set.

** Nota **** Para la explicación utilicé el tipo int, esto mismo es aplicable también para el tipo de objeto.