Необязательная монада и закон Деметры в Java

Ну, вы сами довольно хорошо резюмировали: если вы хотите более свободно соединяться, вводя hasAddress(), зачем возвращать Optional.

Читая то, что говорится в LoD, говорится об "ограниченных" знаниях о "тесно связанных" единицы. Звучит как серая зона для меня, но в дальнейшем здесь также упоминается правило «Только одна точка». Тем не менее, я бы согласился с комментариями к вашему вопросу о том, что нулевая проверка (или isPresent()) совершенно прекрасна (черт возьми, настоящая нулевая проверка технически даже не нуждается в точке ; P ).

Если вы действительно хотите инкапсулировать больше, вы можете полностью удалить getAddress() и вместо этого предложить:

class User {
    private Optional<Address> address;

    boolean hasAddress() {
        return address.isPresent();
    }

    // still exposes address to the consumer, guard your properties
    void ifAddressPresent(Consumer<Address> then) {
        address.ifPresent(then::accept);
    }

    // does not expose address, but caller has no info about it
    void ifAddressPresent(Runnable then) {
        address.ifPresent(address -> then.run());
    }

    // really keep everything to yourself, allowing no outside interference
    void ifAddressPresentDoSomeSpecificAction() {
        address.ifPresent(address -> {
            // do this
            // do that
        });
    }
}

Но опять же, как отметили комментаторы: стоит ли/необходимо? Все эти законы/принципы редко бывают абсолютными и скорее ориентирами, чем догмами. В этом случае речь может идти о балансе LoD и KISS.

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

• конкретный случай
• насколько этот код открыт для других модулей
• количество методов делегата, которые вам понадобятся в классе User
• вашей архитектуры (например, если вы находитесь в классе UserDao, действительно ли вы хотите переместить доступ к базе данных в свой класс User POJO? Разве DAO не создан именно для этой цели? Квалифицируется ли это как «тесно связанный» и допускает нарушение правила «Только одна точка»?)
• ...

Не знаю, чище ли это (поскольку вам нужно использовать тот факт, что getAddress все равно возвращает необязательный параметр), но в Java 9 вы можете сделать:

users.stream()
    .map(User::getAddress)
    .flatMap(Optional::stream)
    .map(/* Some code */)

or

users.stream()
    .flatMap(user -> user.getAddress().stream())
    .map(/* Some code */)

Думаю, вы уже сами ответили на этот вопрос.

Здесь у вас есть два разных варианта использования:

1. Определить, есть ли у пользователя адрес
2. Доступ к адресу пользователя нулевым безопасным способом

Первый вариант использования можно решить, добавив метод hasAddress(), как вы сказали. Второй вариант использования можно решить, используя Optional для переноса адреса. Там нет ничего плохого.

о чем LoD просит вас подумать, так это о том, нужно ли вообще выдавать значение адреса (т. е. запрашивать/доступно). Если ответ ДА ​​- тогда вам нужно иметь дело с нулевым или пустым случаем значения; в противном случае можно подумать о том, можно ли запросить существование адреса или нет.

Таким образом, если он действителен для выдачи адреса, то возврат Optional обрабатывает случай нулевого значения и может использоваться для подтверждения существования. Мне кажется, что проверка необязательности на «пустоту» аналогична проверке целого числа на 0 — вы не получаете доступ к атрибуту какого-либо другого объекта, а просто к атрибуту объекта, который вам дали.

Если разрешено знать только существование, то, вероятно, лучше использовать метод isPresent. Конечно, если вы имеете дело со значением SQL, то, возможно, потребуется необязательный параметр для обработки значения SQL NULL.

Иначе почему здесь происходит эта фильтрация?

Другой подход заключается в переносе вычислений в пользовательский класс.

Поскольку у пользователя есть адрес, он должен иметь возможность отвечать на вопросы об адресе и не должен раскрывать его. Таким образом, вы удовлетворите LoD