Si examina el código fuente de JDK para LinkedHashMap, me di cuenta de que esta clase se declara como:LinkedHashMap firma
public class LinkedHashMap<K,V>
extends HashMap<K,V>
implements Map<K,V>
{...
por qué el redundante "implements Map<K,V>" (puesto que ya implementa HashMap Mapa)? No me puedo imaginar que esto sea un error tipográfico ...
Gracias.
supongo que es una forma de decir
No importa qué interfaces HashMap implementos (ahora o en el futuro), esta clase debe implementar la interfaz del mapa.
Si alguien responsable de la HashMap decide que ya no debe implementar la interfaz del mapa, el compilador advertirá al mantenedor de LinkedHashMap que ya no implementa la interfaz del mapa como era su intención.
Por supuesto es una tontería en este caso particular (HashMap obviamente siempre será un Mapa), pero situaciones similares pueden beneficiarse (y han dado lugar a) tal convención.
Parece una convención de estilo/código: LinkedHashSet tiene una firma similar. Tal vez solo sea para enfatizar el uso de la interfaz. Compare con C++, donde es una buena práctica escribir "virtual" con todas las funciones virtuales, incluso si ya son implícitamente virtuales.
Al igual que LinkedList. Supongo que hace más fácil averiguar qué interfaces se implementan. –
Podría haber un error por parte del codificador.
También podrían haber querido hacer explícito el uso de la interfaz. Dado que declararlo dos veces no hace daño más allá de las pulsaciones de tecla adicionales, no tengo ningún problema.
Supongo que permite que LinkedHashMap proporcione una implementación personalizada de los métodos declarados en la interfaz de Map. De esta forma, no heredaría todas las implementaciones de HashMap.
No heredaría los métodos de HashMap de todos modos ... ya que los anularía. – aioobe
Hace que la intención sea más clara, por lo que es obvio que se pretende que sea una implementación de Mapa, con un comportamiento específico, que casualmente se crea al extender HashMap, pudiéndose utilizar en algunos lugares, en lugar de un HashMap.
Es un código antiguo. Hasta cierto punto, alrededor de JDK 1.1.6, Javadoc no mostraba interfaces heredadas, por lo que era habitual o incluso necesario reiterarlas en clases derivadas para que el Javadoc funcione correctamente. Se introdujeron en JDK 1.2 pero estaban disponibles mucho antes como un complemento para 1.1.x.
La misma situación con HashMap y AbstractMap –