Можно ли возвращать null из переопределенного абстрактного метода

#java #design-patterns #overriding #abstract

#java #шаблоны проектирования #переопределение #аннотация

Вопрос:

У меня есть класс SpecialSender , который расширяется abstract class Sender . В абстрактном классе есть метод sendFile , но мой отправитель просто отправляет простую строку, поэтому я не хочу использовать sendFile . Это хорошая практика:

     @Override
    protected String sendFile(Product product, Type type) {
        return null;
    }

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

1. Как документируется метод, что, по его словам, он может вернуть? Я хочу сказать, что здесь нет правила, но если в документации суперкласса указано что-то конкретное, вы должны следовать этому, иначе вы должны правильно документировать, что он возвращает null

2. вы возвращаете null, потому что вам нужно вернуть null или потому, что класс не должен поддерживать это действие?

3. @JoakimDanielson protected abstract String sendFile(Product product, Type type) throws Exception; только это. @Stultuske, я возвращаю null, потому что мой класс не должен поддерживать эту операцию

4. @Michu93 для этого существует определенный тип исключения: UnsupportedOperationException

Ответ №1:

Я думаю, что вам лучше применить принцип разделения интерфейса.

Что означает, что вместо Sender класса есть абстрактный метод sendFile . У вас может быть интерфейс, подобный ISendFile методу abstract / default sendFile . Так что требуемый подкласс отправителя может быть реализован ISendFile .

Пример:

 abstract class Sender{

  protected void send();

}

interface ISendFile{

default String sendFile(Product product, Type type) {
        .......
        return string;
    }
}

class SpecialSender extends Sender{

@Override
    protected String send() {
        return null;
    }
}

class EmployeeSender extends Sender implements ISendFile {

@Override
    protected String send() {
        ......
    }

 @Override
    String sendFile(Product product, Type type) {
        .....
    }
}

1. как это было бы лучше? Вы все еще предоставляете реализацию, где реализация не гарантируется. наличие методов по умолчанию в (новых) интерфейсах на самом деле не лучший дизайн IMO

2. В приведенном выше примере класс SpecialSender не имеет метода sendFile .

3. согласен, но теперь вы меняете исходную начальную точку, не зная, является ли это опцией для OP