Обсудить реферат и интерфейс в Java

Java задняя часть
Обсудить реферат и интерфейс в Java

«Это третий день моего участия в ноябрьском испытании обновлений. Подробную информацию об этом событии см.:Вызов последнего обновления 2021 г."

  • Готовьтесь к весеннему набору или летней стажировке 2022 года, и я желаю вам всем миллион очков прогресса каждый день!Day7
  • Эта статья обобщает «Аннотация и интерфейс в Java», которая будет обновляться ежедневно ~
  • Для получения знаний, таких как «Приступая к освоению Redis» и «Параллельное программирование», вы можете обратиться к моим предыдущим блогам.
  • Верь в себя, живи сильнее, Пока ты жив, ты должен открыть дорогу в горах и построить мост через воду! Жизнь, ты на меня надави, я подарю тебе чудо!

image.png

1. Введение

Ключевые слова abstract и interface можно увидеть повсюду в Java, и это один из важных столпов реализации трех основных функций Java: инкапсуляции, наследования и полиморфизма. Ключевое слово interface используется для определения абстракции интерфейса, которая по существу используется дляВозможность определять типы, определять классы. Однако новички часто неправильно используют abstract и interface, и Xiaoba фактически делает ту же ошибку.В этой статье мы обсудим использование interface interface и abstract abstract class.


Перед началом статьи рекомендуется ознакомиться с двумя вопросами:

  1. В чем разница между abstractи interface?
  2. Как следует выбирать абстракцию и интерфейс?

2. Рекомендации

При определении интерфейса есть несколько рекомендаций, на которые вы можете ссылаться.Согласно этим рекомендациям вы можете лучше определить, следует ли вам определять интерфейс или есть другие лучшие альтернативы. (Обратите внимание, что то, что сказал Сяоба, не совсем правильно. В реальном процессе разработки нам нужно подробно проанализировать это. Если что-то не так, мы можем общаться друг с другом.)

2.1 Интерфейсы имеют приоритет над абстрактными классами

Здесь Xiaoba использует систему наследования исходного кода JDK HashMap, чтобы проиллюстрировать, что интерфейсы имеют приоритет над абстрактными классами.

Структура диаграммы классов системы наследования HashMap:

Интерфейс верхнего уровня HashMap:

public interface Map<K,V>{}

Абстрактный класс, реализованный HashMap:

public abstract class AbstractMap<K,V> implements Map<K,V> {}

Вы видите, что HashMap наследует абстрактный класс AbstractMap и реализует интерфейс Map, но почему вы говорите, что интерфейс имеет приоритет над абстрактным классом? это потому чтоJava — это множественная реализация единого наследования, HashMap не может наследовать другие классы после наследования абстрактного класса AbstractMap. Если это интерфейс, такого ограничения нет. Например, HashMap также должен предоставлять функции сериализации и клонирования. HashMap может реализовать три интерфейса Map, Клонируемый, сериализуемый.

В таком случае, почему HashMap должен наследовать абстрактный класс AbstractMap?

Это связано с тем, что при разработке исходного кода JDK структура карты JDK должна обеспечивать реализацию некоторых методов по умолчанию, поэтому авторы JDK отдельно вытащили абстрактный класс для реализации этих методов; хотя Oracle Java8 пытается предоставить статические методы и обычные методы в интерфейсе, но Сяоба считает, что если нет определенного уровня спроса, реализация метода не должна быть определена в интерфейсе в максимально возможной степени или даже вообще.

В чем разница между абстракцией и интерфейсом?

На самом деле после Java8 разница стала сокращаться, но в целом по-прежнему есть два совершенно разных понятия:

Особенности абстрактного класса:

  • И абстрактные методы, и абстрактные классы должны быть изменены с помощью ключевого слова abstract.
  • Если у класса есть абстрактные методы, то класс должен быть абстрактным.
  • Абстрактные классы не обязательно имеют абстрактные методы
  • Конструкторы могут существовать в абстрактных классах
  • Обычные свойства, методы, статические свойства и статические методы могут существовать в абстрактном классе.
  • Методы абстрактного класса должны быть реализованы в подклассе, в противном случае подкласс также должен быть определен как абстрактный класс.
  • Абстрактные классы не могут использовать new для создания объектов, потому что вызов абстрактных методов без реализации бессмысленен.

Особенности интерфейса:

  • Все методы в интерфейсе модифицируются публичными
  • В интерфейсе нет конструктора, объект интерфейса не может быть создан
  • В интерфейсе только константы, если определена переменная, по умолчанию добавляется public static final.
  • Множественное наследование с использованием интерфейсов
  • В интерфейсе есть только объявления методов, нет тела метода (применимо до Java8, когда я этого не говорил, но многие люди так думают, такое неправильное мышление часто может правильно спроектировать код)
  • Статические методы могут быть объявлены в интерфейсе, который должен быть изменен общедоступным (по умолчанию), и статические методы не могут быть переопределены подклассами.
  • В интерфейсе могут быть объявлены обычные методы, которые должны быть изменены по умолчанию.
сравнение абстрактный класс интерфейс
множественное наследование Не поддерживается (можно наследовать только один абстрактный класс) Поддержка (классы могут реализовывать множество интерфейсов)
метод Абстрактный класс может содержать как абстрактные, так и неабстрактные методы. Все методы в интерфейсе неявно абстрактны (Java может определять статические методы).
Конструктор разрешать не положено
создавать экземпляр не может быть создан не может быть создан
модификатор доступа Абстрактные классы могут использовать public, default, абстрактные методы могут использовать public, default, protected, общие методы могут использовать public, default, protected, private. Интерфейсы могут использовать public и default, методы по умолчанию public;

Суммировать:

  1. Во всей системе абстрактной реализации должна быть предусмотрена реализация некоторых методов по умолчанию, и можно использовать абстрактные классы (поскольку крайне не рекомендуется реализовывать некоторые методы непосредственно в интерфейсе)
  2. Если вам не нужно предоставлять реализацию по умолчанию, и вам нужно реализовать несколько функций наследования, используйте интерфейс

2.2 Методы не должны быть реализованы в интерфейсах

Интерфейсы вездесущи.Являясь верхним уровнем архитектуры классов, все ограничения и спецификации, предоставляемые интерфейсом, напрямую влияют на классы реализации более низкого уровня. Поэтому не рекомендуется реализовывать определенные методы в интерфейсах.Хотя определения интерфейса после Java 8 могут обеспечить реализацию статического метода и реализацию общего метода, этот метод реализации имеет большие риски, если только ваш дизайн интерфейса не является действительно совершенным, таким совершенным. реализация классов может сказать, что ваша логика никогда не изменится. В противном случае после изменения логики конкретного метода реализации интерфейса пострадают следующие классы, использующие этот метод.

Таким образом, интерфейс должен использоваться только в максимально возможной степени.Определите типы, определите возможности классов. Если вам необходимо определить реализацию, рассмотрите возможность использования абстрактного класса для ее определения.


2.3 Интерфейсы не должны использоваться для экспорта констант

Поскольку постоянная определения в интерфейсе очень удобно, некоторые мелкие партнеры будут использовать интерфейс непосредственно как класс постоянного экспорта, такой как следующий путь:

/**
 * <p>
 *      缓存key
 * </p>
 *
 * @Author: Liziba
 * @Date: 2021/11/2 23:12
 */
public interface CacheKey {

    String USER = "user";

    String ORDER = "order";

    String MAIL = "mail";

}

Несмотря на то, что это выглядит очень просто, в использовании нет никаких проблем. Но проблема в том, что интерфейс не используется для экспорта констант для вас.Если вам нужно определить константы, мы можем использовать перечисление или константные классы, такие как следующий метод:

public class CacheKey {

    public static final String USER = "user";

    public static final String ORDER = "order";

    public static final String MAIL = "mail";

}

Обратите внимание, что здесь Сяоба сказал не использовать интерфейстолько экспортировать классы как константы, вместо того, чтобы говорить, что константы не могут быть определены в интерфейсах.Если некоторые константы единообразно используются в абстрактных типах классов, такой дизайн можно рассмотреть (но это не рекомендуется!),Часто лучше выделить класс констант для управления этими константами.