Лямбда-выражение и статические поля или поля экземпляра - PullRequest
Новая
       31

Лямбда-выражение и статические поля или поля экземпляра

0 голосов
/ 24 мая 2018

Мы знаем, что лямбда-выражение может ссылаться и использовать статические переменные экземпляра, переменные экземпляра и локальные переменные (если они фактически являются окончательными).Все это выглядит нормально.Всякий раз, когда я вижу какую-либо сессию в Lambdas и Java, посвященную функциональному программированию, я вижу одну общую мысль: «Написание параллельного кода - это сложная задача, и поэтому адаптация функционального кода помогает».Однако, если я могу получить доступ к статическим переменным и переменным экземпляра в лямбда-выражении, это не устраняет эту проблему вообще.Я знаю, что у нас есть параллельные потоки, которые очень полезны в некоторых параллельных случаях, но все же это область замыкания, не нарушенная в Java, если мы идем к функциональному стилю программирования.

Также мы должны создавать чистые функции в функциональном стиле программирования.Однако, если я зависим от состояния экземпляра, тогда моя функция не чистая.

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

public class UsingStaticVariables {

    static int staticTest = 10;

    public static void main(String args[]) {

        staticTest++;
        System.out.println("Static test first value is " + staticTest);
        Supplier<Integer> supplier = () -> {return staticTest++; };
        staticTest++;
        System.out.println("Static test second value is " + staticTest);
        System.out.println("Static Test lambda output is " + supplier.get());

    }
}

1 Ответ

0 голосов
/ 24 мая 2018

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

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

Я знаю, что у нас есть параллельные потоки, которые очень полезны в определенном параллельном случае, но при этом область закрытия не нарушается в Java, если мыстремятся к функциональному стилю программирования.

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

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

[W], так как есть особая причина, по которой это разрешаетсяэти принципы проектирования [?]

Мотивация для большей части разработки языка Java и стандартной библиотеки почти всегда заключалась в том, чтобы упростить использование языка различными способами, для стольких задач программирования, скольковозможный.Кажется, что лямбды были мотивированы гораздо большим желанием уменьшить важность анонимных внутренних классов, чем каким-либо идеалом обеспечения лучшей поддержки стиля функционального программирования.Угол FP в основном подходит для поездки, хотя стандартная библиотека, кажется, действительно зацепилась за это.

...