Map, como inicializo

[Maverickhunter]

Hola a todos,

Navegando me di cuenta que la clase Map (Si es que es clase), servía para ciertos propósitos que necesito, el problema es que no se como inicializarla (que no sea null) para poder comenzar a introducirle Objetos.

Código PHP:

  Map miMap=null; 
while(unBool) 
{ 
   //algo 
   miMap.put(key,value); 
}  
   

Marca error debido a que miMap es null, investigue y no veo ni constructores ni como inicializarla, mientras estoy usando Hashtable pero ocupa más espacio en memoria. Que puedo hacer?

[kittya]

map es una interfaz y ademas estas llendo al tope

la hashtable si usa mucha memoria pero es por si quieres que tus busquedas sean rapidas

puede usar una clase AbstractMap como clase tienen su constructor e implementa a Map

[Maverickhunter]

Muchas Gracias!!!

AbstracMap me sirvió muy bien...

que significa que sea una interfaz y no una clase?

[Maverickhunter]

Ya meconteste:

Un interface es una colección de declaraciones de métodos (sin definirlos) y también puede incluir constantes.

Runnable es un ejemplo de interface en el cual se declara, pero no se implemementa, una función miembro run.

public interface Runnable {
public abstract void run();
}

Las clases que implementen (implements) el interface Runnable han de definir obligatoriamente la función run.

class Animacion implements Runnable{
//..
public void run(){
//define la función run
}
}

El papel del interface es el de describir algunas de las características de una clase. Por ejemplo, el hecho de que una persona sea un futbolista no define su personalidad completa, pero hace que tenga ciertas características que las distinguen de otras.

Clases que no están relacionadas pueden implementar el interface Runnable, por ejemplo, una clase que describa una animación, y también puede implementar el interface Runnable una clase que realice un cálculo intensivo.

------------------------

jaja como si no supiera usar el google perdon se me fue

[stock]

Las interfaces son usadas para el correcto diseño de un sistema, generalemente se utilizan en grandes sistemas, tambien son muy utilizadas en juegos, en finnnnnn son muy utiles, por ejemplo regresando al MAP, puedes instanciarlo asi:

Map map = new TreeMap();
Map map2 = new HashMap();

por que ambas clases implementan ala interface MAP, en fin, las interfaces las usas en el patron MethodFactory tambien

have funnnnnn

[GreenEyed]

¿Una Hashtable ocupa más espacio en memoria que un Map? Y esa afirmación se basa en...¿? .

[Maverickhunter]

Iniciado por GreenEyed

¿Una Hashtable ocupa más espacio en memoria que un Map? Y esa afirmación se basa en...¿? .

Un Hashtable permite colisiones, un Map no, en el hashtable usa listas para guardar los multiples Objetos con una misma llave (default 10 espacios reservados para colisiones). Map al guardar un solo elemento por llave ocupa menos espacio.

[GreenEyed]

Teniendo en cuenta que Map es una interfaz y por lo tanto no tiene implementacion por si misma, y que Hastable implementa la interfaz Map y por tanto "un Hastable es un Map"... esa me parece una afirmación muy aventurada .

Y teniendo en cuenta que la clase Hashtable no especifica en el API si permite o no colisiones, y por lo tanto es un aspecto que puede cambiar en diferentes implementaciones del JDK, yo no me basaría en esa información para mis elecciones ya que al cambiar de JDK puede que se comporte de forma totalmente diferente.

PD: Y para no confundir a la gente, una Hastahble no permite objetos almacenados por la misma "clave" si no que puede que varias "claves" diferentes devuelvan el mismo hashCode o "clave interna" para la indexación.

[Maverickhunter]

Iniciado por GreenEyed

Teniendo en cuenta que Map es una interfaz y por lo tanto no tiene implementacion por si misma, y que Hastable implementa la interfaz Map y por tanto "un Hastable es un Map"... esa me parece una afirmación muy aventurada .

Efectivamente Hashtable es un Map, pero yo me refería que no requería un Map a un nivel de detalle de Hashtable.

Iniciado por GreenEyed

Y teniendo en cuenta que la clase Hashtable no especifica en el API si permite o no colisiones, y por lo tanto es un aspecto que puede cambiar en diferentes implementaciones del JDK, yo no me basaría en esa información para mis elecciones ya que al cambiar de JDK puede que se comporte de forma totalmente diferente.

el JDK al que me basaba es el Std. Ed. v1.4.2

Iniciado por GreenEyed

PD: Y para no confundir a la gente, una Hastahble no permite objetos almacenados por la misma "clave" si no que puede que varias "claves" diferentes devuelvan el mismo hashCode o "clave interna" para la indexación.

Efectivamente así es como maneja las colisiones para ese JDK... gracias por la aclaración

[GreenEyed]

Iniciado por Maverickhunter

Efectivamente Hashtable es un Map, pero yo me refería que no requería un Map a un nivel de detalle de Hashtable.

Si, entiendo que te refieres a que una Hastable puede utilizar más memoria que otra implementacion que no permita colisiones, pero a cambio una que no permita colisiones puede ser más lenta puesto que debe solucionar las colisiones que se produzcan de otra forma (re-creando claves internas hasta dar con una que no le cree conflicto), sólo lo decía en forma de chiste por que la frase "literal" no tiene sentido por que Hastable implementa Map. De todas formas, leí que HashMap (otra implementación de Map más moderna) es idéntica en esa parte de la implementación, así que no se si hay alguna que no tenga ese "problema", que yo no lo veo.

Iniciado por Maverickhunter

el JDK al que me basaba es el Std. Ed. v1.4.2

Si, con lo de la versión quiero decir que tu puedes leer y hacer mediciones con el JDK1.4.2, pero como NO está documentado en el API, Sun lo puede cambiar cuando/cuanto quiera. Quizá la 1.4.3 lo haga de otra forma y entonces todo lo que has calculado y/o hecho para evitarlo ya no sirve de nada. De todas formas, excepto para casos excepcionales y críticos, este tipo de detalles son practicamente irrelevantes, excepto a nivel académico, y a la hora de la verdad, es mejor concentrar las energias en cosas que dan una mejor relacion tiempo/beneficio.

Un ejemplo típico es "optimizar" un query, haciéndolo mucho más difícil de mantener y utilizando aspectos específicos del driver JDBC, para pasar, por ejemplo, de 150ms a 50ms una consulta. Eso significa triplicar la velocidad de la consulta, pero si es para una aplicación web donde el tiempo de respuesta total de esa consulta es de 1,5s, en realidad resulta que has complicado enormente tu diseño y lo has hecho dependiente del driver para ganar sólamente un 10% de velocidad que quizá no te compense. Y luego cambia la version de BDD y resulta que en realidad sales perdiendo por que han optimizado esa parte pero como tu la usas de otra forma...

Es sólo un ejemplo, pero esas cosas pasan y por eso la primera regla de la optimización es empezar por las "presas" gordas, jugosas y fáciles y sólo ir a las pequeñas y de resultado incierto en caso de extrema necesidad .

S!

[Maverickhunter]

Iniciado por GreenEyed

Es sólo un ejemplo, pero esas cosas pasan y por eso la primera regla de la optimización es empezar por las "presas" gordas, jugosas y fáciles y sólo ir a las pequeñas y de resultado incierto en caso de extrema necesidad .

S!

mi caso era de resultado incierto (era porque ya entregue el proyecto ), pero tienes razón mejor no me complico.

Gracias a los que respondieron

[GreenEyed]

Ah ok. Ya digo que para cuestiones "académicas" puede que se le de importancia, que no deja de tenerla aunque relativa, pero en el mundo real ya veras que hay otras prioridades que pasan delante .

Suerte con el proyecto, si no te dieron la nota todavía, o espero que te fuese bien si ya te la dieron .