Есть ли веские причины для публичного конструктора абстрактного класса - PullRequest
38 голосов
/ 25 января 2011

Невозможно создать объект, напрямую вызвав конструктор класса abstract.Конструктор класса abstract может быть вызван только из производного класса.Поэтому мне кажется , что конструкторы абстрактного класса должны быть либо protected, либо частными для пакета (последний для необычных случаев ограничения использования конструктора для производных классов в пакете).Тем не менее, Java позволяет конструктору abstract быть public.

. Есть ли обстоятельства, при которых полезно объявить конструктор класса abstractpublic, а не protected или приватный пакет?

Это не совсем дубликат вопроса " Модификатор доступа к конструктору абстрактных классов ": очевидно, вы можете объявить конструктор public;Я хочу знать, есть ли когда-нибудь хорошая причина для этого.Мне кажется, что нет.Я вижу, что C # имеет похожую особенность .

Ответы [ 4 ]

19 голосов
/ 25 января 2011

Ответ для java одинаков:

Нет никаких причин для открытого конструктора абстрактного класса.Я предполагаю, что причина, по которой компилятор не жалуется, заключается в том, что они просто не тратят время на его освещение, поскольку на самом деле не имеет значения, является ли он открытым или защищенным.( source )

Вы не можете вызывать конструктор абстрактного класса из чего-либо, кроме прямого подкласса.

Таким образом, добавление специального правила для модификаторов доступа конструкторов абстрактных классов не добавит в язык ничего полезного.


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

public abstract class A {
  public A() {}
}

public class B extends A {}

Таким образом, мы можем создать B, вызвав new B() - но обратите внимание, что мы все еще создаем B, а не A.И, опять же, не имеет значения, является ли конструктор в A открытым или защищенным.Он просто не должен быть закрытым, но компилятор заметит и пожалуется ...

На самом деле мы вызываем "невидимый" публичный конструктор по умолчанию для B, который выполняет простой super() вызов ...

0 голосов
/ 04 февраля 2018

Видимость также влияет на то, что отображается в javadoc (если оно выбрано для исключения определенных уровней видимости).Иначе это не имеет значения, это может быть использование для открытого конструктора абстрактного класса.

Если вы не предоставите конструктор, тогда конструктор по умолчанию будет общедоступным, если класс общедоступен.Самый простой вариант - разрешить это, а не принудительно использовать защищенные конструкторы.

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

0 голосов
/ 29 марта 2014

Назовите меня еретиком, но ... Я вижу, по крайней мере, одно использование конструктора в абстрактном классе.

То есть: чтобы указать, как выглядят параметры конструктора.

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

Я не вижу другого способа указать обязательные сигнатуры конструктора (помогите, если вы это сделаете).

0 голосов
/ 25 января 2011

Вы можете иметь открытый конструктор, если вы не определили конструктор в подклассе. Пример

abstract class Animal {
   String name;
   public void Animal(String name) {
         this.name = name;
   }
}


class Cat extends Animal{
    public String sayMayName() {
       return this.name;
    }
}

myCat = new Cat("tester");

name = myCat.sayMyName();

если конструктор не определен, будет вызван конструктор родительского класса, если он не является общедоступным, он не будет работать. Я думаю, что это более элегантно сделано с помощью фабричного шаблона, но я использовал его на практике в PHP, и он отлично работает.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...