Конструктор допускается в абстрактном классе, но не в интерфейсе

Question

Поправьте меня, если я ошибаюсь

Приведенный выше заголовок приближает меня к следующим выводам:

1) Конструктор - это ничто иное, как конкретный метод с именем класса и без возвращаемого типа, даже void.

2) И, абстрактный класс может иметь как конкретные, так и абстрактные методы; поэтому иметь конструктор в абстрактном классе - это все равно, что иметь конкретный метод. Это нормально, пока конструктор не будет вызван в этом абстрактном классе.

Что касается вызова, нам нужно создать и возразить, что является концепцией создания экземпляра, то есть против протокола абстрактного класса. Однако этот конструктор можно вызвать после расширения этого абстрактного класса до конкретного класса и создания объекта конкретного класса.

3) Интерфейс не может иметь конструктора, потому что он чисто абстрактный. Он не поддерживает конкретные методы. И, следовательно, даже не конструктор

Answer 1

Первая точка

Это метод, который автоматически вызывается при создании объекта. Рассматривайте это как объект, созданный слушателем.

Вторая точка

Подклассы должны вызывать родительский конструктор в самом первом операторе. Конструктор является инициализатором объекта. Как я уже сказал, это можно рассматривать как слушатель объекта строительства.

параметры

Параметры, которые принимает конструктор, зависят от того, как вызывающий объект создает объект, и для параметров абстрактного класса, как подкласс передает параметры с super(...) на самом деле является частью определения класса подкласса о том, как он расширяет суперкласс. Это также объясняет, почему super(); не требуется, если конструктор суперкласса не принимает аргументы.

Третий пункт

Абстрактные классы - это классы.

Абстрактные классы тоже классы; не различайте их. Класс - это то, что содержит поля класса и методы класса; это очень простое определение класса, поэтому экземпляры класса называются объектами. Абстрактный класс удовлетворяет этому; просто некоторые из его методов не являются реальными методами, но они все еще являются методами с точки зрения вызывающей стороны. Например, вызывающей стороне не нужно знать, является ли метод абстрактным или нет при его вызове.

C++ сравнение

Если мы посмотрим на C++, (который afaik является источником / вдохновением / моделью / чем-то еще для классов Java), мы обнаружим, что методы класса не обязательно имеют реализацию (хотя, если вы этого не сделаете, будет ошибка, забыл время выполнения или время компиляции) но только прототип. Java abstract Метод похож на метод C++ без прототипа. (У меня нет опыта работы с C++, поэтому эта часть может быть неточной)

Это показывает, что значение abstract в абстрактном классе только означает, что он (i) не может быть создан и (ii) может содержать абстрактные методы. Абстрактный метод в суперклассе означает, что этот метод должен существовать, но подклассы должны реализовать его сами; и так как абстрактный класс не может быть создан, безопасно иметь abstract (или если это вас раздражает, считайте это пустым / return null метод) метод в нем.

А как насчет интерфейсов?

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

Почему нет методов конструктора?

Почему ты вообще этого хочешь? Вы не создаете экземпляр объекта из имени интерфейса.

Если вы думаете об ограничении аргументов в конструкторах, таких как registerSubclass(Class<? extends ThisSuperclass>) вид API типов регистра, где у вас может быть такой код:

abstract class Handler{
    public static <T> void registerHandler(Class<T extends Handler> clazz){
        Constructor<T> c = clazz.getConstructor(Event.class); // say, you have to construct subclasses to handle an event
        // a lot of try-catch trouble
    }
}

Однако до сих пор эта функция не существует в Java, и вы должны проверить конструкторы самостоятельно (по крайней мере, насколько мне известно).

Как насчет методов по умолчанию?

Методы по умолчанию добавляются в Java 8, где интерфейсы могут иметь конкретные методы. Я не знаком с концепцией или крайними случаями этой новой функции, но ссылаюсь на "автомобильную" аналогию из документации по Java по интерфейсам, если interface Car - это спрос клиента на то, что вам нужно произвести, чтобы он купил ваш автомобиль, стандартные методы в интерфейсах: "Я хочу, чтобы в машине был кондиционер, но, поскольку вам это может быть трудно, я даю вам эту систему кондиционирования. изобрел, вы можете сделать другую систему кондиционирования, хотя ".

Почему нет конструктора по умолчанию в интерфейсах?

Как я уже упоминал, конструкторы похожи на слушатель, сконструированный объектами, поэтому это не метод с этой точки зрения, а часть структуры класса (например, extends предложение, аннотации или другие модификаторы класса). Интерфейсы определяют методы, требуемые от вас. Метод по умолчанию - это всего лишь фиктивный метод, в основном полезный для обратной совместимости в интерфейсах. Но это очень неразумно для конструктора по умолчанию, потому что это не метод в этом смысле.

Отказ от ответственности: я никогда не изучал Java должным образом из учебных пособий, поэтому мое понимание основано на моих собственных наблюдениях в течение более 2 лет, но до сих пор это, кажется, правильно объясняет классы Java. В практическом программировании эти концепции на самом деле не имеют значения, если вы правильно понимаете семантику, хотя легче понять семантику правильно, если вы понимаете концепции.

Answer 2

Если вы спрашиваете, почему или почему не абстрактный или интерфейсный класс не может (не может) иметь конструктор, тогда это может помочь:), а затем это.