Java constructor — необязательный аргумент в конструкторе подкласса

#java #inheritance #constructor #subclass #superclass

#java #наследование #конструктор #подкласс #суперкласс

Вопрос:

Общая система здесь представляет собой своего рода библиотеку. У меня есть вызываемый суперкласс Person с двумя конструкторами: один, который принимает имя и фамилию в виде отдельных строк, а другой, который принимает эти параметры, а также ArrayList для средних имен — идея в том, что у некоторых людей нет среднего имени. В вызываемом подклассе Member я хочу иметь возможность создавать объект-член с отчеством или без него, передавая пустой ArrayList . Моя первая мысль была примерно такой:

 if (middleNames.size() == 0) {
    super(firstName, lastName);
} else {
    super(firstName, middleNames, lastName);
}
 

Но теперь я понял, что super() конструктор должен быть первым оператором в конструкторе подкласса. Надеюсь, вы понимаете, что я пытаюсь здесь сделать — есть ли хороший способ сделать это, не записывая два конструктора в классе-члене? Есть несколько строк кода, которые я бы предпочел не повторять.

Комментарии:

1. Какие бы строки кода вы не хотели повторять, можете ли вы просто поместить это в метод в классе Person ?

2. Я не вижу реальной причины поступать подобным образом. Делают ли ваши конструкторы суперкласса разные вещи? Я имею в виду, что если Person бы у вас был только один конструктор, который проверял бы, является ли middleNames аргумент пустым или нет, а затем выполнял бы определенные действия самостоятельно, чтобы любые подклассы даже не беспокоились о том, чтобы делать то же самое?

3. @PaulSamsotha будет ли это приемлемо для конструктора? Для пояснения — строки кода составляют остальную часть конструктора.

4. Кроме того, Person конструктору, вероятно, было бы лучше принять Collection вместо ArrayList (по соображениям дизайна) и проверить с isEmpty() помощью вместо size() == 0 (по соображениям производительности).

5. @fluffy — поскольку порядок (средних) имен важен, а не просто любой Collection , он должен быть тем, который определяет / поддерживает порядок; List это был бы обычный выбор. Кроме того, Донаг, согласно комментарию NomadMaker, см. раздел «Ложь, в которую программисты верят в отношении имен». shinesolutions.com/2018/01/08 /…

Ответ №1:

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

 class Member extends Person {
    static Member create(String firstName, List<String> middleNames, String lastName) {
        if (middleNames.isEmpty()) {
            return new Member(firstName, lastName);
        }
        return new Member(firstName, middleNames, lastName);
    }

    private Member(String firstName, String lastName) {
        super(firstName, lastName);
    }

    private Member(String firstName, List<String> middleNames, String lastName) {
        super(firstName, middleNames, lastName);
    }
}
 

Комментарии:

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