Глядя на исходный код JDK для LinkedHashMap, я заметил, что этот класс объявлен как:LinkedHashMap подпись
public class LinkedHashMap<K,V>
extends HashMap<K,V>
implements Map<K,V>
{...
почему лишними «implements Map<K,V>» (с HashMap уже реализует Map)? Я не могу представить, что это опечатка ...
Спасибо.
Я предполагаю, что это способ не говоря
Независимо от того, какие интерфейсы HashMap орудия (в настоящее время или в будущем), этот класс должен реализовывать интерфейс Map.
Если кто-то отвечает за HashMap решает, что он больше не должен реализовывать интерфейс Map, компилятор будет предупреждать сопровождающее LinkedHashMap, что он больше не реализует интерфейс Map, как он предназначен.
Конечно, это глупо в этом конкретном случае (HashMap, очевидно, всегда будет Картой), но подобные ситуации могут выиграть (и дали начало) такой конвенции.
Кажется, что стиль/код конвенции: LinkedHashSet имеет аналогичную подпись. Возможно, это просто подчеркнуть использование интерфейса. Сравните с C++, где хорошая практика писать «виртуальные» со всеми виртуальными функциями, даже если они уже неявно виртуальны.
Как и LinkedList. Я думаю, это облегчает работу над интерфейсами. –
Может быть ошибкой со стороны кодера.
Возможно, они также захотели использовать явный интерфейс. Поскольку объявление его дважды не наносит вреда, кроме лишних ключевых штрихов, у меня нет проблем с ним.
Мое предположение - позволить LinkedHashMap предоставлять пользовательскую реализацию методов, объявленных в интерфейсе карты. Таким образом, он не наследовал бы всех реализаций из HashMap.
В любом случае, это не наследует методы от HashMap .. так как это переопределит их. – aioobe
Это делает цель более четкой, так что очевидно, что это предназначено для реализации карты с конкретным поведением, которое, кстати, создается путем расширения HashMap, благодаря чему его можно использовать в некоторых местах, в место HashMap.
Это древний код. До некоторой точки вокруг JDK 1.1.6 или около того Javadoc не показывал унаследованные интерфейсы, поэтому было принято или действительно необходимо повторять их в производных классах, чтобы заставить Javadoc работать правильно. Они были представлены в JDK 1.2, но были доступны до этого в качестве дополнения для 1.1.x.
Такая же ситуация с HashMap и AbstractMap –