Использование записей Java 14 для общих (не связанных с данными) классов только с конечными полями

Question

Учитывая простой класс с конечным полем, например String (см. пример ниже) или зависимости Spring, рекомендуется использовать запись Java 14, чтобы сделать ее более краткой и, возможно, удалить обработчики аннотаций, такие как Lombok?

Согласно JEP, описывающему записи, "записи делают семантическое заявление о том, что они являются простыми и прозрачными держателями своих данных".

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

Следовательно, этого "достаточно", чтобы считать это "злоупотреблением" этой особенностью языка? Или есть другие, менее очевидные недостатки?

@RequiredArgsConstructor // or an explicit constructor when not using lombok
class AudienceValidator implements OAuth2TokenValidator<Jwt> {
    private final String audience;

    public OAuth2TokenValidatorResult validate(Jwt jwt) {
        // validate
    }
}


record AudienceValidator(String audience) implements OAuth2TokenValidator<Jwt> {

    public OAuth2TokenValidatorResult validate(Jwt jwt) {
        // validate
    }
}

Answer 1

Здесь это зависит от предполагаемой семантики, но исходя из того, что я вижу здесь, это, вероятно, злоупотребление. ЯвляетсяAudienceValidatorего состояние и ничего, кроме его состояния? Все ли его поведение проистекает из его состояния (способnorm() метод будет происходить из реальной и мнимой частей Complex)?

Лучший способ думать о записях - это номинальные кортежи, которые можно улучшить с помощью поведения. (Полезная аналогия: перечисления Java относятся к перечислениям C, как записи относятся к структурным кортежам.) Кажется, это не то, что вы здесь делаете, и поэтому клиенты были бы справедливо сбиты с толку, увидев этот класс в API, представленном как запись, но ведет себя иначе.

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