Ленивые вычисления в Java с ленивым типом

Некоторые другие монады могут показаться очень похожими на нашу Lazy Например, Future<A>FutureCompletableFuture Большая разница с Lazy<A>LazyFuture Кроме того, все другие характеристики, такие как способ их составления с использованием mapflatMap

Лучший способ справиться с эффектами

В нашем примере мы вызывали метод get Другими словами, мы извлекли значение из его контекста, чтобы применить к нему эффект. Это отменяет эффект лени. Конечно, иногда это в конечном итоге необходимо, но мы должны стараться как можно больше откладывать это. Функциональные программисты-фундаменталисты используют для этого очень сложные методы, но для начала мы можем использовать гораздо более простые.

Преобразование, которое мы реализовали выше, состоит из введения необработанной функции в контекст лени, а не извлечения значения для передачи его функции. Мы можем сделать то же самое с эффектами. Вместо вызова getLazy Для этого мы будем использовать метод, который мы будем вызывать для forEach Это позволяет нам абстрагироваться от принципа, сходного для большинства контекстов, под одним именем.

Реализация очень проста:

 default void forEach(Consumer<A> c) {
    c.accept(get());
}

Используя этот метод, наш последний пример можно переписать так:

 public static void main(String... args) {
    Lazy<String> message = lazyGreetings
        .flatMap(greetings -> lazyFirstName
            .flatMap(firstName -> lazyLastName
                .map(lastName -> String.format(
                        "%s, %s %s!", greetings, firstName, lastName))));
    System.out.println("Message has been composed but nothing has been evaluated yet");
    message.forEach(System.out::println);
}

Обратите внимание, что наш метод forEachConsumerкаждому значению в контексте. Тот факт, что для Lazy Важно четко видеть, что это та же концепция, что и для forEachStream Это (помимо всего прочего) то, что OptionalifPresentforEachStream

Запоминание результата оценки

Наш интерфейс допускает отложенную оценку, но не позволяет повторно использовать значение после его оценки. Это означает, что если мы хотим использовать значение дважды, не пересчитывая его, мы должны где-то его сохранить. Было бы более практично, чтобы Lazy

Но интерфейс не может хранить значения, поэтому мы должны выбрать другой дизайн. Вместо создания интерфейса, расширяющего SupplierSupplier Этот класс будет хранить как Supplier<A>A

 public class Lazy<A> {

    private final Supplier<A> sValue;

    private A value;

    private Lazy(Supplier<A> value) {
        this.sValue = value;
    }

    public A get() {
        // Note that the following code is not thread safe. Thread safety
        // is not implemented here to keep the code simple, but can be
        // added easily.
        if (value == null) {
            value = sValue.get();
        }
        return value;
    }

    public <B> Lazy<B> map(Function<A, B> f) {
        return new Lazy<>(() -> f.apply(this.get()));
    }

    public <B> Lazy<B> map(Function<A, B> f, B defaultValue) {
        return new Lazy<>(() -> {
            try {
                return f.apply(this.get());
            } catch (Exception e) {
                return defaultValue;
            }
        });
    }

    public <B> Lazy<Optional<B>> mapOption(Function<A, B> f) {
        return new Lazy<>(() -> {
            try {
                return Optional.of(f.apply(this.get()));
            } catch (Exception e) {
                return Optional.empty();
            }
        });
    }

    public <B> Lazy<B> flatMap(Function<A, Lazy<B>> f) {
        return new Lazy<>(() -> f.apply(get()).get());
    }

    public void forEach(Consumer<A> c) {
        c.accept(get());
    }

    public static <A> Lazy<A> of(Supplier<A> a) {
        return new Lazy<>(a);
    }

    public static <A> Lazy<A> of(A a) {
        return new Lazy<>(() -> a);
    }

}

Обратите внимание на наличие двух статических фабричных методов, чтобы разрешить создание Lazy<A>Supplier<A>A Запуск следующего теста показывает преимущества запоминания:

 static Lazy<String> name1 = Lazy.of(() -> {
    System.out.println("Evaluating name1");
    return "Bob";
});

static Lazy<String> name2 = Lazy.of(() -> {
    System.out.println("Evaluating name2");
    throw new RuntimeException();
});

static Function<String, String> constructMessage =
        name -> String.format("Hello, %s!", name);

public static void main(String... args) {
    String defaultValue = "Sorry, but I don't talk to anonymous people.";
    name1.map(constructMessage, defaultValue).forEach(System.out::println);
    System.out.println("----");
    name2.map(constructMessage, defaultValue).forEach(System.out::println);
    System.out.println("----");
    name1.mapOption(constructMessage).forEach(System.out::println);
    System.out.println("----");
    name2.mapOption(constructMessage).forEach(System.out::println);
}

Результат показывает, что успешная оценка происходит только один раз:

 Evaluating name1
Hello, Bob!
----
Evaluating name2
Sorry, but I don't talk to anonymous people.
----
Optional[Hello, Bob!]
----
Evaluating name2
Optional.empty

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

Резюме

Мы узнали, как эффективно реализовать лень типа:

• Использование Supplier
• Составление ленивых типов, чтобы получить ленивый результат
• Сопоставление функции, возвращающей вычисленное значение, с отложенным типом
• Сопоставление функции, возвращающей ленивое значение ленивому типу
• Применение эффекта к ленивым типам
• Памятные ленивые типы

Изучая эти методы, мы обнаружили, что лень является вычислительным контекстом . Мы научились

• Поместите выражение в контекст
• Объединить значения в контексте
• Применить эффект к значениям в контексте

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