Необязательно <T>для входного параметра метода

Question

Я создал общий интерфейс, который реализуется определенными классами.Это выглядит следующим образом:

public interface KingdomElementService<T> {

  public T findById(Long id);

  public T save(Optional<T> object);

  public void update(T t);

}

Мой IntelliJ кричит о сохранении, написав «Optional используется в качестве параметра».Я понимаю логику, что странно воспринимать то, что может существовать, а может и нет.Почему я решил сделать это - переписать некоторые

 if(something){
   do();
 }
 else{
 throw new Expression();
 }

в

something.orElseThrow(Expression::new);

Теперь мне интересно, является ли мое решение использования Optional здесь избыточным или нет.Как вы думаете?Должен ли я рассмотреть вопрос об изменении его обратно?

Answer 1

Кажется, что если у вас есть экземпляр KingdomElementService<T>, вы хотите, чтобы вызывающие абоненты save имели возможность передать экземпляр T или нет.Таким образом, учитывая некоторые переменные:

KingdomElementService<T> kes = ... ;
T someT = ... ;

Абоненты могут сделать это:

kes.save(Optional.of(someT)); // 1
kes.save(Optional.empty());   // 2

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

interface KingdomElementService<T> {
    T save(T t);
    T save();
}

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

kes.save(someT); // 1
kes.save();      // 2

По сути, Optional не помогает API, которые хотят принимать необязательные параметры.

Answer 2

Ничего конкретного против Optional, но используя это в качестве параметра, вы заставляете всех вызывающих абонентов передавать Optional этому методу.Я бы предпочел использовать @Nullable для этого, например:

public T save(@Nullable T object);

Это будет означать, что вам придется написать этот if..else блок (или троичный оператор), но, на мой взгляд, сложность выполнения этого будетбыть намного меньше, чем принуждать ваших клиентов передавать Optional.

Кроме того, вы можете написать Optional.of(object); в качестве первой строки в реализации вашего метода и использовать его для остальной части кода метода, если вы хотитеиспользуйте ту же структуру управления.

Answer 3

Архитекторы языка Java разделяют мнение, что Optional следует использовать только как тип возвращаемого значения.Это означает, что тип возвращаемого значения может быть null.Поэтому необходимо соблюдать осторожность.

Optional, поскольку входной параметр потребует от вас всегда проверять наличие параметра, добавляя некоторые проверки.Если вы хотите добавить какие-либо проверки, вы можете поставить их также без Optional.Нет дополнительной ценности в маркировке входных параметров как Необязательных.

Также вызывающему методу, который передает параметр другому методу, принимающему Optional, придется обернуть объект и отправить.Это накладные расходы.

Я не рассматривал случаи Edge.

РЕДАКТИРОВАТЬ: Изменено с 'Ясный язык достаточно ясен' на что-то более правдивое.

Answer 4

Когда у вас есть метод, такой как save(Optional<T> object);

Я все еще могу сделать вызов save(null);, поэтому опциональный здесь не имеет смысла.

Вы можете реализовать простую проверку на ноль вваш метод

void save(T object){
        if(object == null){
            // do smth
        }
    }

Или используйте Optional.ofNullable () внутри метода

void save(T object){
    Optional.ofNullable(object)
        .map(..)
    .orElseGet(IllegalAccessError::new);
}