Waarom implementeert HashMap Map als het AbstractMap uitbreidt?

Possible Duplicate:
Java.util.HashMap — why HashMap extends AbstractMap and implement Map?

In java to implement HashMap we need to implement Map.

Nochtans toen ik meer debugged in javalklassen schijnt schijnt het dat .... java HashMap klasse als volgt definieert.

public class HashMap extends AbstractMap implements Map, Cloneable, Serializable

At the same time i saw public abstract class AbstractMap implements Map it also implements the interface Map.

If abstract class implements the interface then, what is the reason behind implementing Map at HashMap class level?

Volgens mijn begrip HashMap klasse hebben alle methoden geërfd van AbstractMap die kan worden overschreven door HashMap volgens de vereiste.

13
Zie this . Het wijst op een soortgelijke situatie
toegevoegd de auteur Priyank Doshi, de bron
Ja ... het moet als een duplicaat worden gesloten.
toegevoegd de auteur Stephen C, de bron
@ user845279 - Nee. Omdat dat niet het geval is.
toegevoegd de auteur Stephen C, de bron
Misschien was de klasse, toen deze in Java 1.2 was ontworpen, nodig om de interface te implementeren, zelfs als de superklasse IMO al had geïmplementeerd.
toegevoegd de auteur Luiggi Mendoza, de bron
Is het niet om te laten zien dat alle methoden expliciet zijn gedefinieerd in de kinderklasse?
toegevoegd de auteur user845279, de bron

4 antwoord

In dit specifieke geval is het puur voor documentatiedoeleinden; d.w.z. om de lezer duidelijk te maken dat deze is implementatie van een kaart . Ik ben er vrij zeker van dat er verwaarloosbare kosten zijn in dit stukje redundantie.

(En ja, uw begrip klopt.)

6
toegevoegd

Het is waarschijnlijk alleen maar om dingen duidelijker te maken. Je kunt in principe direct zien aan de hand van de code van die ene klasse dat HashMap de Kaart -interface implementeert. Ja, het breidt al AbstractMap uit, maar dat wordt waarschijnlijk alleen beschouwd als een implementatiedetail.

Er is niets mis met het opnieuw implementeren van interfaces. Dat verandert niets aan de manier waarop de code wordt samengesteld, maar het helpt zeker omdat je het meteen ziet. U hoeft niet eerst de klassenhiërarchie te beklimmen of de API-documenten eerst te laden.

6
toegevoegd

De "implementeert kaart" is optioneel en is er meestal om mensen te helpen bij het lezen van de code dat HashMap de interfacemethoden van Map implementeert, evenals de abstracte methoden van AbstractMap.

3
toegevoegd

Ik geloof dat de redenering hierachter een abstracte klasse in Java is, hoeft niet alle methoden in de interface te declareren/implementeren. Dus

public interface MyInterface{
  void a();
  void b();
  void c();
}

de volgende abstracte implementatie van de interface is geldig.

public abstract class AbstractClass implements MyInterface {
  public void a() {}
  public void c() {}
  public void d() {}
}

Dus ik geloof dat om expliciet te zijn over HashMap het implementeren van de methoden die niet door de abstracte klasse zijn geïmplementeerd, het wordt getoond om de interface Kaart te implementeren, terwijl het volledig optioneel is om dit te doen omdat elke implementatie van de abstracte klasse moet alle methoden implementeren, hetzij in de abstracte klasse of de afgeleide basisklasse. Dus in het bovenstaande voorbeeld is een geldige implementatie naar de abstracte klasse

public class MyClass extends Abstract{
      public void a() {}
      public void c() {}
      public void b() {}  //if you dont implement this, compile error
      public void d() {}
    }

welke je ook als volgt kunt herschrijven:

public class MyClass extends Abstract implements MyInterface {
      public void a() {}
      public void c() {}
      public void b() {}
      public void d() {}
    }
1
toegevoegd
wat precies mijn punt was ..
toegevoegd de auteur Baz1nga, de bron
Geen reden om dit te doen, als een abstracte klasse een interface implementeert, hoeft deze niet alle methoden te implementeren, de eerste "niet-abstracte" klasse die de abstracte klasse moet moet de "niet-abstracte" geïmplementeerde "methoden.
toegevoegd de auteur Luiggi Mendoza, de bron