Привет, Хабр! Представляю вашему вниманию перевод статьи Романа Провазника — Why FP matters even for OOP developer?
Однажды меня очень заинтересовало функциональное программирование, я стал изучать его и рассказывать всем своим знакомым о том, какое оно замечательное. Позже я наткнулся на статью о функциональном программирования с точки зрения ООП программиста и решил перевести ее для вас. Не судите строго, это мой первый перевод.
Меня попросили высказать личное мнение о функциональном программировании с объективно-ориентированной точки зрения. Меня даже заставили создать аккаунт на Медиуме. Как экс-ООП разработчик и на данный момент когда-нибудь-я-стану-настоящим-ФП-программистом, я думаю, мне есть что сказать:
Если ты не провел последние 60 лет на другой планете (если и так, добро пожаловать обратно, путешественник), ты наверняка слышал о функциональном программировании. Если ты следишь за современными трендами в индустрии программного обеспечения, ты слышишь такие термины как «функциональное программирование», «неизменяемость», «чистые функции» и «композиция» ежедневно. Все это звучит круто, восхитительно и понятно пока ты не задумываешься: «Эй, я же ООП-программист и не могу (или не хочу) менять парадигму. Что функциональное программирование может мне дать? Почему я должен заморачиваться?» Как ФП программист/энтузиаст, пришедший из мира ООП, я хочу поделиться тем, что сам хотел бы знать еще много лет назад. Об этом можно говорить часами, поэтому выберем три самые важные вещи.
Традиционным преимуществом ФП является слово, которое обычно занимает как минимум два слайда каждой презентации о функциональном программировании. Серебряная пуля ФП, так ведь? Не совсем. Несмотря на то, что это слово чаще всего используется в основном функциональными программистами, оно не эксклюзивно для ФП. Как ООП разработчик ты можешь достичь (почти) такого же уровня неизменяемости как и ФП разработчик. На самом деле, это достаточно легко, просто нужно взглянуть немного иначе на твои объекты и коллекции. Представь, что ты не изменяешь оригинал, а создаешь новую версию. Добавил элемент в коллекцию? Отлично! Ты не изменил первоначальную коллекцию, вместо этого у тебя просто новая коллекция, содержащая добавленный элемент. Поменял свойство объекта? Здорово! Теперь у тебя новый объект с измененным свойством.
Знаю, знаю — звучит странно. Но это небольшое переключение сознания позволит тебе спать спокойнее. Как только ты поймешь, что твои объекты не могут быть изменены (только скопированы), ты будешь уверен, что никто в команде не сможет переназначить их в каком-либо другом месте. Это как одолжить твою любимую, древнюю аудиокассету Пинк Флойд без страха получить ее обратно перезаписанную с Джастином Бибером. И как бонус, у твоего кода будут полностью отслеживаемые методы, в которых происходят реальные изменения (где создаются новые объекты на основе оригинальных). И, чуть не забыл, если ты C# или Java разработчик, ты уже используешь их, вызывая «ToLower()», «Trim()» на строках, которые изначально неизменяемы. То есть по сути ничего нового.
Другое модное словосочетание, ошибочно считающееся исключительно ФП. Что такое «чистая функция»? Проще говоря, чистая функция — это функция, которая возвращает одинаковый результат при одинаковом входном значении, без связи с «внешним миром» (операции ввода-вывода, общее состояние и т.п.), также известными как «побочные эффекты». Типичным примером данного вида функции может быть получение длины строки (ты же не будешь подключаться к базе данных чтобы посчитать количество символов в строке?), вычисление синуса и так далее. Какая выгода от этого для ООП? Такая же как и для ФП. Если ты работаешь с чистыми функциями (или методами), ты точно знаешь какой результат получишь для каждого входного значения. И если твой код не зависит от какого-то скрытого состояния, его очень легко протестировать, и тебя не напряжет написать юнит-тест. Мы все знаем, что без взаимодействия с внешним миром наше ПО было бы бесполезным, но есть ощутимая разница между чистым кодом (написанном чистыми функциями/методами) с вводом-выводом только на границах системы и системой, в который каждый метод зависит от внутреннего состояния, обновляемого другими методами.
Еще раз, небольшое переосмысление подхода к вводу-выводу дает все преимущества ФП, плюс тестирование становится насколько простым, что начнет наконец приносить удовольствие.
Мы уже поменяли точку зрения на наш код — мы можем писать более безопасный (неизменяемый) и тестируемый (чистый) код. Теперь настало время пойти чуть дальше и поменять подход к определению того, что наше ПО должно делать. Что еще так значительно отличает ООП от ФП? В функциональном мире мы определяем «что» должно происходить вместо определения «как» должно происходить. Конечно, остается часть программы, которая выполняют ту конкретную операцию, но тут важно сконцентрироваться на выражениях вместо утверждений. И это то, что ты можешь делать в любимом ООП языке.
Например, если тебе знакомы такие вещи, как LINQ (из C#), ты уже знаешь преимущества выражений запросов, когда ты можешь прочитать свой код как «Ага, здесь я беру 10 элементов из коллекции, сортирую их по алфавиту и использую как параметр для следующего метода». Ты наверняка читал тысячи подобных LINQ выражений без необходимости задумываться, что же на самом деле происходит за кулисами. И это самое главное, концентрироваться на том, что реально имеет значение.
Я думаю на этом пока достаточно. Я не хочу в итоге продавать ФП как серебряную пулю. Мир не только черный и белый. Правда в том, что для меня ФП невероятно сложно. Почти также сложно, как правильное ООП. Но его определенно стоит попробовать. С моей точки зрения ООП vs ФП — это по большому счету то, как я задумываюсь о коде и его структуре. Как я думаю о зависимостях, побочных эффектах, всём мире ввода-вывода и тестирования. Если подытожить одной мыслью, то «Функциональный подход поможет, вне зависимости от языка, предметной области и платформы.»
Однажды меня очень заинтересовало функциональное программирование, я стал изучать его и рассказывать всем своим знакомым о том, какое оно замечательное. Позже я наткнулся на статью о функциональном программирования с точки зрения ООП программиста и решил перевести ее для вас. Не судите строго, это мой первый перевод.
Меня попросили высказать личное мнение о функциональном программировании с объективно-ориентированной точки зрения. Меня даже заставили создать аккаунт на Медиуме. Как экс-ООП разработчик и на данный момент когда-нибудь-я-стану-настоящим-ФП-программистом, я думаю, мне есть что сказать:
Добро пожаловать, путешественник
Если ты не провел последние 60 лет на другой планете (если и так, добро пожаловать обратно, путешественник), ты наверняка слышал о функциональном программировании. Если ты следишь за современными трендами в индустрии программного обеспечения, ты слышишь такие термины как «функциональное программирование», «неизменяемость», «чистые функции» и «композиция» ежедневно. Все это звучит круто, восхитительно и понятно пока ты не задумываешься: «Эй, я же ООП-программист и не могу (или не хочу) менять парадигму. Что функциональное программирование может мне дать? Почему я должен заморачиваться?» Как ФП программист/энтузиаст, пришедший из мира ООП, я хочу поделиться тем, что сам хотел бы знать еще много лет назад. Об этом можно говорить часами, поэтому выберем три самые важные вещи.
Неизменяемость
Традиционным преимуществом ФП является слово, которое обычно занимает как минимум два слайда каждой презентации о функциональном программировании. Серебряная пуля ФП, так ведь? Не совсем. Несмотря на то, что это слово чаще всего используется в основном функциональными программистами, оно не эксклюзивно для ФП. Как ООП разработчик ты можешь достичь (почти) такого же уровня неизменяемости как и ФП разработчик. На самом деле, это достаточно легко, просто нужно взглянуть немного иначе на твои объекты и коллекции. Представь, что ты не изменяешь оригинал, а создаешь новую версию. Добавил элемент в коллекцию? Отлично! Ты не изменил первоначальную коллекцию, вместо этого у тебя просто новая коллекция, содержащая добавленный элемент. Поменял свойство объекта? Здорово! Теперь у тебя новый объект с измененным свойством.
Знаю, знаю — звучит странно. Но это небольшое переключение сознания позволит тебе спать спокойнее. Как только ты поймешь, что твои объекты не могут быть изменены (только скопированы), ты будешь уверен, что никто в команде не сможет переназначить их в каком-либо другом месте. Это как одолжить твою любимую, древнюю аудиокассету Пинк Флойд без страха получить ее обратно перезаписанную с Джастином Бибером. И как бонус, у твоего кода будут полностью отслеживаемые методы, в которых происходят реальные изменения (где создаются новые объекты на основе оригинальных). И, чуть не забыл, если ты C# или Java разработчик, ты уже используешь их, вызывая «ToLower()», «Trim()» на строках, которые изначально неизменяемы. То есть по сути ничего нового.
Чистые функции
Другое модное словосочетание, ошибочно считающееся исключительно ФП. Что такое «чистая функция»? Проще говоря, чистая функция — это функция, которая возвращает одинаковый результат при одинаковом входном значении, без связи с «внешним миром» (операции ввода-вывода, общее состояние и т.п.), также известными как «побочные эффекты». Типичным примером данного вида функции может быть получение длины строки (ты же не будешь подключаться к базе данных чтобы посчитать количество символов в строке?), вычисление синуса и так далее. Какая выгода от этого для ООП? Такая же как и для ФП. Если ты работаешь с чистыми функциями (или методами), ты точно знаешь какой результат получишь для каждого входного значения. И если твой код не зависит от какого-то скрытого состояния, его очень легко протестировать, и тебя не напряжет написать юнит-тест. Мы все знаем, что без взаимодействия с внешним миром наше ПО было бы бесполезным, но есть ощутимая разница между чистым кодом (написанном чистыми функциями/методами) с вводом-выводом только на границах системы и системой, в который каждый метод зависит от внутреннего состояния, обновляемого другими методами.
Еще раз, небольшое переосмысление подхода к вводу-выводу дает все преимущества ФП, плюс тестирование становится насколько простым, что начнет наконец приносить удовольствие.
Декларативное VS Императивное
Мы уже поменяли точку зрения на наш код — мы можем писать более безопасный (неизменяемый) и тестируемый (чистый) код. Теперь настало время пойти чуть дальше и поменять подход к определению того, что наше ПО должно делать. Что еще так значительно отличает ООП от ФП? В функциональном мире мы определяем «что» должно происходить вместо определения «как» должно происходить. Конечно, остается часть программы, которая выполняют ту конкретную операцию, но тут важно сконцентрироваться на выражениях вместо утверждений. И это то, что ты можешь делать в любимом ООП языке.
Например, если тебе знакомы такие вещи, как LINQ (из C#), ты уже знаешь преимущества выражений запросов, когда ты можешь прочитать свой код как «Ага, здесь я беру 10 элементов из коллекции, сортирую их по алфавиту и использую как параметр для следующего метода». Ты наверняка читал тысячи подобных LINQ выражений без необходимости задумываться, что же на самом деле происходит за кулисами. И это самое главное, концентрироваться на том, что реально имеет значение.
Резюме
Я думаю на этом пока достаточно. Я не хочу в итоге продавать ФП как серебряную пулю. Мир не только черный и белый. Правда в том, что для меня ФП невероятно сложно. Почти также сложно, как правильное ООП. Но его определенно стоит попробовать. С моей точки зрения ООП vs ФП — это по большому счету то, как я задумываюсь о коде и его структуре. Как я думаю о зависимостях, побочных эффектах, всём мире ввода-вывода и тестирования. Если подытожить одной мыслью, то «Функциональный подход поможет, вне зависимости от языка, предметной области и платформы.»