Que bueno que hayan podido ponerlo

Saludos

Interesante post, no conocía este framework!!!

Saludos

Que bueno!!! espero no perdermelo.

Saludos

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

CitarOnce V2 10000 numeros en 0.275 segundos

Falta un 0 o me parece a mí?

Tiene razon fermino. A todos los tiempos de Once o le falta un 0 o es mas lento.
Felicidades a todos.

Saludos

Bienvenido Burkraith!!!
Espero que te sientas cómodo.
Ante cualquier cosa, no dudes en preguntar.

Saludos

Comparto este post porque me parecio bastante buena la ayuda que puede ser tener los digramas de Venn para entender los joins


Hace ya algún tiempo, mientras aprendía a hacer consultas avanzadas a SQL a marchas forzadas, empecé a buscar información que me explicara mejor cómo funcionaban los JOINs de SQL. ¡Hay tantos! La verdad es que al principio, cuesta entenderlos bastante.

Pero entonces me topé con un artículo que el bueno de Jeff Atwood (creador de Stackoverflow) escribió allá por el 2007. Jeff, utiliza diagramas de Venn para explicar de manera muy concisa cada JOIN. Soy consciente de que mucha gente no busca en inglés por lo que me dije, ¿por qué no lo traducimos?

Si has intentado comprender cómo funcionan los JOINs y no acabas de entenderlos y, lo que es peor, dudas sobre qué JOIN usar, tan solo debes tener una imagen en mente. Con estos sencillos ejemplos, pretendo solo que te hagas a la idea de lo que un JOIN en concreto te devolverá.

Tengamos estas dos tablas como ejemplos:

id nombre     id  nombre
-- ------     --  ------
1  Homer      1   Marge
2  Bart       2   Homer
3  Marge      3   Spidercerdo
4  Maggie     4   Moe

Vamos a unir las tablas por el campo del nombre de distintas formas y vamos a ver cómo resultan.

Inner join

SELECT * FROM TablaA 
INNER JOIN TablaB
ON TablaA.nombre = TablaB.nombre

id  nombre     id   nombre
--  ------     --   ------
1   Homer      2    Homer
3   Marge      1    Marge

Un inner join produce únicamente el conjunto de registros que están tanto en la Tabla A como en la Tabla B.

Full outer join

SELECT * FROM TablaA
FULL OUTER JOIN TablaB
ON TablaA.nombre = TablaB.nombre

id    nombre     id    nombre
--    ------     --    ------
1     Homer      2     Homer
2     Bart       null  null
3     Marge      1     Marge
4     Maggie     null  null
null  null       3     Spidercerdo       
null  null       4     Moe

Full outer join produce el conjunto de todos los recursos de la Tabla A y de la Tabla B, haciendo coincidir los registros de ambos lados si están disponibles. Si no hay coincidencias, el lado que falte, contendrá null.

Left outer join

SELECT * FROM TablaA
LEFT OUTER JOIN TablaB
ON TablaA.nombre = TablaB.nombre

id  nombre     id    nombre
--  ------     --    ------
1   Homer      2     Homer
2   Bart       null  null
3   Marge      1     Marge
4   Maggie     null  null

Left outer join reproduce todos los registros de la Tabla A, con los registros completos (donde se pueda), de la Tabla B. Si no hay coincidencias en el registro, el lado derecho contendrá null.

Estas son las operaciones básicas que podemos hacer con JOIN. No obstante, vamos a ver algunos trucos para obtener otras partes de las tablas que nos puedan interesar.

SELECT * FROM TableA
LEFT OUTER JOIN TableB
ON TableA.name = TableB.name
WHERE TablaB.id IS null

id  nombre     id     nombre
--  ------     --     ------
2   Bart       null   null
4   Maggie     null   null

Para obtener los registros que solo estén en la Tabla A, pero no en la Tabla B, realizaremos el mismo left outer join, y excluimos los registros de la derecha que no queremos, con where.

SELECT * FROM TablaA
FULL OUTER JOIN TablaB
ON TableA.nombre = TablaB.nombre
WHERE TablaA.id IS null 
OR TablaB.id IS null

id    nombre     id    nombre
--    ------     --    ------
2     Bart       null  null
4     Maggie     null  null
null  null       3     Spidercerdo
null  null       4     Moe

En este caso, obtendremos los registros únicos de la Tabla A y de la Tabla B. Para lograrlo, ejecutamos el mismo full outer join, y luego excluimos los resultados indeseados de ambos lados con where.

Ten en cuenta que, aunque no están aquí incluidos por parecerme redundante, podemos cambiar LEFT por RIGHT si queremos darle la vuelta al gráfico, operando así con la tabla derecha como principal, en vez de la izquierda

Fuente: funcion13
Autor: Antonio Laguna

Saludos

Buenas les dejo un pequeño desafío, bastante fácil sobre excepciones.


Objetivos:

Decir cuál sería la salida al siguiente código y por qué es esa salida, o por qué no es otra.

La idea del desafío es dar una primera respuesta sin tener que recurrir a ejecutar el código.

Usuarios que contestaron bien al desafio:

- fermino
- LKI

Saludos

Guia definitiva para montar un servidor GNU/Linux Profesional.

Guia ilustrada paso a paso para novatos y expertos.

Descarga: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Fuente: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Saludos

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
Una pregunta en donde puedo descargar el magazine ?

Puedes verla o descargarlo desde aqui: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

como te dije por el irc, con esta pagina puede ir descifrando  manualmente No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
Eso para el primer var y para el segundo solo toma los valores del primer array.

Saludos

Felicidades a hdbreaker y muy bueno el solucionario. Servirá de mucho para aprender.

Saludos

Sobreescritura y sobrecarga de métodos son 2 conceptos que pueden parecer confusos pero veremos que en sí representan algo muy simple.

Debemos saber que estas propiedades de la Programación Orientada a Objetos nos traen algunas ventajas como por ejemplo la facilidad, extensibilidad y flexibilidad en el código.

Pero que son?

La sobrecarga y sobreescritura no son mas que dos conceptos aplicados al trabajo con métodos, específicamente en el uso que le queremos dar. Estos conceptos dependen principalmente de nuestra lógica de programación y el enfoque o forma de trabajo, depende de lo que queremos hacer. ¿Como así?, veamos de forma mas clara cada concepto.

Sobrecarga de métodos (Overloading)

En java sabemos que si ya declaramos una variable o un método con un nombre en especifico, no podemos declarar otra variable o método que se llame igual, sin embargo esta regla no aplica cuando usamos la Sobrecarga de métodos, ya que esta permite usar el mismo nombre del método pero solo si se tiene diferente firma, ¿firma?, cuando hablamos de la firma de un método, nos referimos a sus parámetros.

En resumen la sobrecarga permite declarar métodos que se llamen igual pero que reciban parámetros diferentes (no pueden haber 2 métodos con el mismo nombre y los mismos parámetros), por esta razón lo que define a que método se ingresa, son los argumentos que se envían como parámetros.

Anteriormente mencioné algo sobre la forma de trabajo o lógica de programación, esto es porque supongamos que yo quiero hacer sumas, pero mi programa debe sumar por aparte 2 números enteros o 2 números doubles, para esto tengo 2 opciones.

1. crear 2 métodos, uno llamado sumaEnteros(int a, int b) y otro sumaDoubles(double a, double b)

2. Aplicar el concepto de sobrecarga, donde aunque también vamos a crear 2 metodos, los vamos a llamar con el mismo nombre pero con diferentes parametros, sumar(int a, int b) y sumar(double a, double b) quedando algo como esto:

public void sumar(int a, int b) {
        int suma=a+b;
        System.out.println("la suma es: "+suma);
}
     
public void sumar(double a, double b) {   
        double suma=a+b;
        System.out.println("la suma es: "+suma);
}

Podemos ver que los 2 métodos se llaman igual pero poseen parámetros diferentes, así cuando sean llamados, dependiendo del parámetro enviado se accede al método.

Y no es igual? para que sobrecargar si en ultimas se crea el mismo numero de métodos? 

La pregunta anterior es muy valida y tiene mucha lógica, pero como en otros casos la respuesta también gira en torno a la facilidad, las buenas practicas y la búsqueda de aplicaciones optimizadas. El ejemplo es muy simple y poco complejo, pero imaginemos una aplicación donde se tenga la misma acción pero con procesos diferentes?

Por ejemplo encender un motor y si tenemos diferentes tipos de encendido como el eléctrico, encendido térmico, encendido de combustión etc etc. donde los procesos son muy diferentes pero en ultimas el objetivo es el mismo, pero cada uno necesita ciertas características únicas para encender, aquí podríamos aplicar la sobrecarga para no preocuparnos por llamar los métodos por su nombre sino tan solo llamando al mismo pero enviando los parámetros (características) propios de cada tipo de motor y listo, dependiendo de lo que mandemos java sabrá que motor queremos iniciar.

Sobreescritura de métodos (Overriding)

La Sobreescritura es la forma por la cual una clase que hereda puede re-definir los métodos de su clase Padre, de esta manera puede crear nuevos métodos con el mismo nombre de su superClase.

Es decir, si tengo una clase padre con el método ingresar() yo puedo crear en la clase hija un método que también se llame ingresar() pero implementándolo según lo que necesite (siguiendo obviamente unas reglas que veremos mas adelante) a esto se le llama sobreescritura.

Y para que? si cuando se hereda se pueden usar los métodos de la superClase sin tener que declararlos otra vez, entonces porque sobreescribirlos?

Esta pregunta es muy común, la respuesta es que también depende de lo que queremos hacer, si lo que queremos es extender una funcionalidad por medio de la herencia y si bien, en la clase padre existe el método ingresar(), el método y la lógica que tenga es propia de esa clase, si yo quiero vincularle algo mas a ese método pero que sea especifico para la clase hija, no podría, ya que tendría que modificarlo en la clase padre y de esta manera ya se perdería el enfoque como tal, pues dicha funcionalidad sería común para todas las clases hijas que hereden de la superClase.

Por la razón anterior, la sobreescritura nos permite extender la funcionalidad de un método heredado para hacerlo especifico a lo que necesitemos, pudiendo implementar la lógica que queramos en nuestras clases hijas para el mismo método.

Y cuales son las reglas?

Así como en la sobrecarga nos fijamos en los parámetros, en la sobreescritura nos debemos fijar en que la estructura del método sea igual a la de su superClase, no solo el mismo nombre sino el mismo numero de argumentos y tipo de retorno (o al menos un subtipo de este), así como no tener un nivel de acceso mas restrictivo que el original (que en la clase padre sea protected y en la hija sea private por ejemplo) tampoco se pueden sobreescribir métodos static ni final. (ya que static representa métodos globales y final constantes.)

Algo que también debemos mencionar es que podemos identificar un método sobreescrito cuando tiene la anotación @override, esto es muy común encontrarlo cuando trabajamos con clases abstractas o interfaces, donde se obliga a implementar los métodos de estas si son heredadas o implementadas respectivamente, sin embargo no es obligatorio ponerlo pero si  es recomendable, pues de esta manera el compilador reconoce que se están sobreescribiendo los métodos ayudando a que si nos equivocamos al crear un método distinto, el compilador nos avisaría. Adicionalmente si tenemos la anotación inmediatamente podremos saber que se está aplicando el concepto, algo muy útil cuando trabajamos con código de otras personas.

Veamos un ejemplo donde se sobreescribe el método tocar()

Public class Instrumento{
        public String tipo;
 
        public abstract void tocar() {
                System.out.println("Tocar un Instrumento");
        }
}
 
 
class Guitarra extends Instrumento {
        @Override        
        public void tocar() {
                System.out.println("Tocar La Guitarra");
        }
}

Como vemos la clase Guitarra hereda de la clase Instrumento, esta ultima tiene el método tocar() con una implementación diferente a la del método en la clase Guitarra (el mensaje es distinto), al tener la anotación @Override nos damos cuenta que se está sobreescribiendo dicho método y se le puede dar la lógica que queramos especifica para la clase Guitarra.

Ingresar a uno u otro método depende de la lógica del llamado, también es algo muy ligado al polimorfismo donde por medio de este se puede acceder a uno u otro método, por ejemplo si queremos acceder al método tocar() de la clase guitarra aplicando la sobreescritura y el polimorfismo tendríamos que hacer una instancia de la clase padre con un objeto de la clase hija así:

Instrumento miGuitarra=new Guitarra();
miGuitarra.tocar();

con esto accederíamos al método tocar de la clase guitarra.

Conclusiones!!!

Como pudimos ver los 2 conceptos son muy similares pero con enfoques totalmente diferentes, en sí el concepto como tal no es confuso y a medida que se va conociendo de a pocos su aplicación tampoco lo será.

Y Listo!!!!! con esto vimos a nivel general lo que representan la sobrecarga y sobreescritura de métodos, recuerden que la forma de dominarles es la práctica y ver su comportamiento con diferentes ejercicios.

Fuente: codejavu

Saludos

Esperando las proximos numeros

Saludos

Espero que el próximo no ser descalificado por mago oscuro xD jaja

Saludos

Saludos

Buenisimo LKI.
Es una muy buena practicar el patrón mvc.

Saludos

Buenas a todos!!!

Para entender un poco este concepto veamos un ejemplo:

"Una fábrica de juegos de PC desea modelar un sistema de selección aleatoria de Jugadores (RandomSelector). Dado que la selección aleatoria se usa en muchos y variados juegos (p.e: selección aleatoria de números, de cartas, de colores, de fichas, etc.) se detallo que el RandomSelector debería ser diseñado de tal forma que se pueda usar con cualquier tipo de objetos.
El funcionamiento debería ser el siguiente: Una vez creado el RandomSelector con el tipo de Objeto que va a seleccionar este permanece así. Al RandomSelector se le pueden agregar N objetos a seleccionar. Cuando se le dice selectNext() retorna un objeto seleccionado de manera aleatoria."

En java, cuando se define una nueva clase, se debe conocer el tipo de datos con el que se trabajará. Pero en este caso necesitamos que sea independiente al tipo de datos, y así poder reutilizar la clase sin necesidad de hacer alteraciones al código.
Es aquí donde entra el concepto de tipos genéricos.

La utilización seria:

public class RandomSelector<T> {

}

T es un tipo genérico que será sustituido por el tipo real cuando se instancie la clase.
Al RandomSelector se le podía agregar N objetos, vamos a necesitar hacer uso de alguna colección para ir guardando los objetos.

import java.util.ArrayList;
import java.util.Random;

public class RandomSelector<T> {

	private ArrayList<T> elementos;
	private Random rn;
	
	public RandomSelector() {
		this.elementos = new ArrayList<T>();
		this.rn = new Random();
	}

}

Verán como a la colección se le da como tipo de datos a T, el tipo genérico.
rn es de tipo Random, y nos va servir más adelante para la aleatoriedad.
Agregamos el método agregarElemento que recibe como parámetro un objeto de tipo T y lo agrega a la colección.

public void agregarElemento(T elemento) {
	this.elementos.add(elemento);
}

Por otro lado, el método selectNext retorna un elemento de tipo T, y que es el que se ubica en la posición 'x' de la colección elementos. Dichas posición 'x' se obtiene con un numero aleatorio que va desde 0 al tamaño de la colección - 1

public T selectNext() {
	return this.elementos.get(rn.nextInt(this.elementos.size()));
}

Probemos como funcionaría:

public static void main(String[] args) {
	RandomSelector<String> rS1 = new RandomSelector<String>();
	rS1.agregarElemento("Piedra");
	rS1.agregarElemento("Papel");
	rS1.agregarElemento("Tijera");
	System.out.println(rS1.selectNext());
		
	RandomSelector<Integer> rS2 = new RandomSelector<Integer>();
	rS2.agregarElemento(1);
	rS2.agregarElemento(2);
	rS2.agregarElemento(3);
	System.out.println(rS2.selectNext());
}

Usamos un primer objeto RandomSelector con T = String y uno segundo con T = Integer. Y funcionó de igual manera sin importar el tipo

Por último existen una serie de convenciones para nombrar a los genéricos:

• E – Element (usado bastante por Java Collections)
• N – Number (para números)
• K – Key (Llave, usado en mapas)
• T – Type (Representa un tipo, es decir, una clase)
• V – Value (representa el valor, también se usa en mapas)

Saludos

Lo que me motivó a escribir esta guía de colecciones en java es el inmenso tamaño del framework de colecciones que puede echar para a atrás a cualquier programador que se ponga a investigar las APIs sin ordenar un poco las ideas. Hay tantas interfaces e implementaciones que es fácil perderse y no saber que usar en cada momento.

Esta pequeña guía de colecciones en Java pretende explicar, de manera sencilla, que las colecciones en Java y que implementación sería mejor que usases para cada caso.

Este va a ser un post extenso, así que voy a ser tan amable de proporcionaros una pequeña tabla de contenidos.

1- Tipos de colecciones en java

• Listas
• Sets
• Maps
• Colas

2- Listas

• ArrayList
• LinkedList
• Vector
• CopyOnWriteArrayList

3- Sets

• HashSet
• LinkedHashSet
• TreeSet
• EnumSet
• CopyOnWriteArraySet
• ConcurrentSkipListSet

4- Maps

• HashMap
• LinkedHashMap
• TreeMap
• EnumMap
• WeakHashMap
• HashTable
• ConcurrentHashMap

5- Colas

• ArrayDeque
• LinkedBlockingDeque
• LinkedList
• PriorityQueue
• PriorityBlockingQueue

6- Diagramas de clases

• Diagrama de clases: Listas
• Diagrama de clases: Sets
• Diagrama de clases: Maps
• Diagrama de clases: Colas

7- Notas finales

Tipos de colecciones en Java

Los tipos de colecciones vienen representados por interfaces. Una serie de interfaces clasifica las colecciones de Java en los siguientes tipos:

- Listas: Una lista ordenada, o secuencia. Normalmente permiten duplicados y tienen acceso aleatorio (es decir, puedes obtener elementos alojados en cualquier índice como si de un array se tratase).
- Sets: Colecciones que no admiten dos elementos iguales. Es decir, colecciones que no admiten que un nuevo elemento B pueda añadirse a una colección que tenga un elemento A cuando A.equals(B).
- Maps: Colecciones que asocian un valor a una clave. Parecido a la estructura de "array asociativo" que se encuentra en otros lenguajes. Un Map no puede tener dos claves iguales.
- Colas: Colecciones que permiten crear colas LIFO o FIFO. No permiten acceso aleatorio, solo pueden tomarse objetos de su principio, final o ambos, dependiendo de la implementación.

Listas

La colección más básica de Java. También, es la más usada por los programadores que no han investigado el framework de colecciones a fondo por hacernos pensar que se trata de una especie de array hipervitaminado ya que hace su trabajo y es fácil de entender.

Sin embargo, por grande que sea la tentación de usar una lista (como un ArrayList) para todo, ¡has de resistir!

Sabiendo los requisitos de tu aplicación, seguramente encontrarás otra colección que haga el trabajo de una lista mejor. Procura asegurarte de que cuando vas a usar una lista es porque realmente te hace falta, no porque no conoces el resto. La diferencia de rendimiento puede ser enorme. Y cuando digo enorme, me refiero a superior a un 600% en según que operaciones.

¿Qué beneficios tienen las listas?

- Acceso aleatorio.
- Están ordenadas (Podemos usar Colections.sort() para ordenar los elementos siguiendo el criterio que queramos).
- Podemos añadir / eliminar elementos sin ninguna restricción.
- Tienen un iterador especial ListIterator que permite modificar la lista en cualquier dirección.
- Siguen la notación de los arrays, por lo que son fáciles de comprender.

¿Qué problemas tienen las listas?

- Bajo rendimiento en operaciones especialziadas respecto a otras colecciones.

A continuación voy a enumerar todas las listas de Java con sus características, además, daré una pequeña explicación de cuando deberíais usar esa lista.

Tipos de Lista

• ArrayList: Muy rápida accediendo a elementos, relativamente rápida agregando elementos si su capacidad inicial y de crecimiento están bien configuradas. Es la lista que deberías usar casi siempre.
• LinkedList: Una lista que también es una cola (hablaré de esto más tarde). Más rápida que ArrayList añadiendo elementos en su principio y eliminando elementos en general. Utilízala en lugar de ArrayList si realizas más operaciones de inserción (en posición 0) o de eliminación que de lectura. La diferencia de rendimiento es enorme.
• Vector: Terreno peligroso. Vector es una colección deprecated (obsoleta), así que usadla únicamente si necesitáis un ArrayList concurrente. El rendimiento de Vector es superior al de Collections.syncronizedList(new ArrayList()).
• CopyOnWriteArrayList: Colección concurrente que es muy poco eficiente en operaciones de escritura, pero muy rápida en operaciones de lectura. Usala sobre Vector (o synced ArrayList) cuando el número de lecturas concurrentes sea mucho mayor al número de escrituras.

Sets

Los sets, o conjuntos, son colecciones que por norma general no admiten elementos iguales en su interior. Como mencionaba antes, dos elementos A y B son iguales si A.equals(B).

Podemos añadir y eliminar elementos de un set, así como saber si determinado elemento está en un set, pero no tenemos acceso aleatorio, por lo que hay que tener muy claro cuando queremos usarlos.

Una colección normal, en apariencia, nos da todo lo anterior -excepto el hecho de eliminar duplicados-, así que, ¿por qué usar un Set y no una Lista?, el motivo es simple: eficiencia.

Supongamos este código:

List b = new ArrayList();
     
if (!b.contains(1))
    b.add(1);

La funcionalidad es la misma que la de set.add, pero el rendimiento es muchísimo peor, hasta el punto de que podemos tener problemas muy serios cuando añadamos muchos elementos y no queremos eso, ¿verdad?.

¿Qué beneficios tienen los sets?

- No permiten elementos duplicados.
- Implementación muy eficiente de .add para asegurarnos de que no hay duplicados.

¿Qué desventajas tienen?

- No tienen acceso aleatorio.
- Solo algunos tipos de set pueden ordenarse y lo hacen de forma poco eficiente.

¿Cuando deberíamos usar un set sobre una lista?, y ¿qué tipo de set?, veámoslo...

Tipos de Set

• HashSet: La implementación más equilibrada de la interfaz Set. Es rápida y no permite duplicados, pero no tiene ningún tipo de ordenación. Utilízala si necesitas un control de duplicados pero no ningún tipo de ordenación o acceso aleatorio.
• LinkedHashSet: Un HashSet que incluye ordenación de elementos por orden de entrada, una velocidad de iteración mucho mayor y un rendimiento mucho peor a la hora de añadir elementos. Utilizala si necesitas un Set ordenado por orden de inserción o si vas a usar un Set que vaya a realizar solamente operaciones de iteración.
• TreeSet: Un set que incluye una implementación de un árbol rojo-negro. Este Set puede ser ordenado, pero su rendimiento es mucho peor en cualquier operación (menos iteración) respecto aun HashSet. Utilizalo solo si necesitas un Set con un criterio de ordenación específico y ten cuidado con las inserciones.
• EnumSet: La mejor implementación de Set para tipos enumerados (Enum). Utilizala si quieres crear un Set de Enums.
• CopyOnWriteArraySet: Set concurrente que tiene un gran rendimiento de lectura, pero pésimo de escritura, eliminado y contains. Úsalo solo en Sets concurrentes que apenas tengan estas operaciones.
• ConcurrentSkipListSet: Set concurrente y ordenable. Utilizalo solo cuando requieras un Set ordenable (como TreeSet) en entornos de concurrencia. En Sets de tamaños muy grandes su rendimiento empeora notablemente.

Maps

Los maps son colecciones que asocian un valor con una clave. Tanto la clave como el valor pueden ser cualquier tipo de datos de Java: Objetos, primitivos, otras colecciones, etc.

Las implementaciones son muy parecidas a los Sets debido a que, internamente, utilizan un Set (la implementación varía según el tipo de Map) para garantizar que no hay elementos duplicados en las claves.

¿Que ventajas tienen los map?

- Asociación clave -> valor.
- Gracias a que utilizan internamente un Set, garantizan que no habrá dos claves iguales.
- Es fácil reconocer cuando necesitamos usar un Map.

¿Qué desventajas tienen los map?

- Rendimiento no muy elevado comparado con otras colecciones.

Tipos de Map

• HashMap: La implementación más genérica de Map. Un array clave->valor que no garantiza el orden de las claves (de la misma forma que un HashSet). Si necesitas un Map no-concurrente que no requiera ordenación de claves, este es el tuyo. Si os fijais en el código de HashSet, veréis que curiosamente utiliza un HashMap internamente.
• LinkedHashMap: Implementación de map que garantiza orden de claves por su tiempo de inserción; es decir, las claves que primero se creen serán las primeras. También puede configurarse para que la orden de claves sea por tiempo de acceso (las claves que sean accedidas precederán a las que no son usadas). Itera más rápido que un HashMap, pero inserta y elimina mucho peor. Utilizalo cuando necesites un HashMap ordenado por orden de inserción de clave.
• TreeMap: Un Map que permite que sus claves puedan ser ordenadas, de la misma forma que TreeSet. Usalo en lugar de un HashMap solo si necesitas esta ordenación, ya que su rendimiento es mucho peor que el de HashMap en casi todas las operaciones (excepto iteración).
• EnumMap: Un Map de alto rendimiento cuyas claves son Enumeraciones (Enum). Muy similar a EnumSet. Usadlo si vais a usar Enums como claves.
• WeakHashMap: Un Map que solo guarda referencias blandas de sus claves y valores. Las referencias blandas hacen que cualquier clave o valor sea eligible por el recolector de basura si no hay ninguna otra referencia al mismo desde fuera del WeakHashMap. Usa este Map si quieres usar esta característica, ya que el resto de operaciones tienen un rendimiento pésimo. Comúnmente usado para crear registros que vayan borrando propiedades a medida que el sistema no las vaya necesitando y vaya borrando sus referencias.
• HashTable: Map deprecated y concurrente. Básicamente, es un HashMap concurrente que no debes usar nunca. En su lugar, utiliza ConcurrentHashMap.
• ConcurrentHashMap: Un Map concurrente que no permite valores nulos. Sustitución básica de HashTable. Usala si necesitas un HashMap concurrente.

Colas

Las colas son estructuras que ofrecen un gran rendimiento al obtener elementos de su principio o de su final, representando colas LIFO / FIFO, aunque también veremos colas ordenadas en función de otros criterios.

Deberás usar una cola cuando vayas a recuperar siempre el primer o último elemento de una serie. Se usan para implementar las mencionadas colas LIFO / FIFO, así como colas de prioridades (como puede ser un sistema de tareas o de procesos).

Cabe destacar que hay dos tipos de colas, Queues y Deques. Las primeras solo proporcionan métodos para acceder al último elemento de la cola, mientras que las Deques permiten acceder a cualquiera de los dos extremos.

¿Qué ventajas tienen las colas?

- Ofrecen un gran rendimiento al recuperar el primer o último objeto de la cola.
- Permiten crear estructuras LIFO / FIFO o colas de prioridades con muy buen rendimiento.

¿Qué desventajas tienen las colas?

- La iteración por las colas suele ser muy lenta.
- El acceso aleatorio, de la misma manera, es muy lento.

Tipos de colas

• ArrayDeque: Una implementación de Deque de rendimiento excepcional. Implementa tanto cola LIFO como FIFO al ser una Deque y es la Cola que deberías usar si quieres implementar una de estas dos estructuras.
• LinkedBlockingDeque: Una Deque concurrente que has de usar cuando quieras usar un ArrayDeque en entornos multihilo.
• LinkedList: LinkedList, anteriormente mencionada en la sección de listas, también es una Deque, sin embargo, su rendimiento es muy inferior al de ArrayDeque. No deberías usar LinkedList cuando quieras usar una cola.
• PriorityQueue: Una cola que se ordena mediante un Comparator, permitiendo crear una Cola donde el primer elemento no dependerá de su tiempo de inserción, sino de cualquier otro factor (tamaño, prioridad, etc). Deberemos usarlo cuando necesitemos este comparator, ya que ArrayDeque no lo permite.
• PriorityBlockingQueue: La versión concurrente de PriorityQueue.

Diagramas de clases

Para entender mejor el framework de colecciones, nada como un diagrama de clases de todas los tipos de colección. He aquí dicho diagrama, por cortesía de No tienes permitido ver los links. Registrarse o Entrar a mi cuenta:

Diagrama de clases – List


Diagrama de clases – Set


Diagrama de clases – Maps


Diagrama de clases – Colas


Notas finales

A la hora de usar colecciones en Java, lo más importante es elegir el tipo de colección. Cuando trabajemos con colecciones, siempre declararemos las instancias con el nombre de su interfaz, aprovechando el enlace dinamico.

De esta forma, aunque la implementación cambie en el futuro, podemos tener claro que la aplicación no va a dar fallos (ya que estamos usando las interfaces y estas tienen los métodos que usan sus implementaciones).

A la hora de escoger la implementación de cada tipo de colección, debéis fijaros en dos cosas:

- Si estamos trabajando en un entorno concurrente o no.
- En el rendimiento de las operaciones que vamos a necesitar en las distintas implementaciones válidas para nuestro entornos (concurrentes o no).

Sabiendo eso ya podréis empezar a explotar a fondo el Framework de colecciones en Java y no limitaros a usar las colecciones Vanilla, mal de muchos programadores que empiezan en este lenguaje.

Confío en que la lectura haya sido interesante y fructífera, para mi lo ha sido, por lo menos.

Fuente: luaces-novo

Saludos

Escrito por: Macario Polo y Daniel Villafranca

Contenido:

Introducción a la tecnología WEB con J2EE
Introducción a JSP
EJBs
Algunos ejemplos
Ejercicios prácticos

Descarga: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Saludos

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
Man el libro no esta completo, solo viene la introducción o indice de los temas...

Rush en el post se aclara que es el indice.

Saludos