Почему конструктор String здесь должен быть защищен, а не закрытым? - PullRequest
1 голос
/ 22 сентября 2010

Я немного застрял в этом практическом вопросе по SCJP, особенно в строке 5 (с конструктором String). Я думал, что это должно быть частным, но решение «защищено». Я думаю, что защищенный доступ не будет удовлетворять требованию, чтобы все экземпляры Alpha имели альфа-строку String, установленную в A. Если конструктор защищен, то любой другой класс, который также находится в пакете alpha, ИЛИ любой подкласс Alpha независимо от пакета, может вызывать его и установите альфу на то, что он хочет. Amirite? Кто-нибудь может уточнить? Спасибо!

alt text

1 Ответ

3 голосов
/ 22 сентября 2010

Если бы конструктор был закрытым, как бы Бета назвала super(a)?

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

new Alpha("some other value")

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

РЕДАКТИРОВАТЬ: У меня есть:)

Сделайте Alpha абстрактным и делайте то, что вам нравится с конструктором, при условии, что он виден для Beta (public или protected в порядке). Таким образом, третье условие автоматически выполняется, потому что никогда никогда не будет экземплярами просто Alpha!

package alpha;
public abstract class Alpha {
    final String alpha;
    Alpha() { this("A"); }
    public Alpha(String a) { alpha = a; }
}

package beta;

public class Beta extends alpha.Alpha {
    public Beta(String a) { super(a); }
}

Теперь, это требует небольшого толкования пункта 1. Я бы сказал, что экземпляр Beta является экземпляром Alpha (в конце концов, , instanceof вернет true :), так что удовлетворяет пункт 1, но экземпляр Beta не является «объектом типа Alpha», поэтому с пунктом 3 все еще в порядке.

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