Чем функциональное программирование отличается от объектно ориентированного
Перейти к содержимому

Чем функциональное программирование отличается от объектно ориентированного

  • автор:

ФП vs ООП

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

За последние несколько лет мне неоднократно доводилось программировать в паре с людьми, изучающими Функциональное Программирование, которые были предвзято настроены по отношению к ООП. Обычно это выражалось в формe утверждений типа: “Ну это слишком похоже на что-то объектное.”

Я думаю это происходит из убеждения, что ФП и ООП взаимно исключают друг друга. Многие похоже думают, что если программа функциональная, то она не объектно ориентированная. Полагаю, формирование такого мнения — логичное следствие изучения чего-то нового.

Когда мы берёмся за новую технику, мы часто начинаем избегать старых техник, которые использовали раньше. Это естественно, потому что мы верим, что новая техника “лучше” и следовательно старая техника наверное “хуже”.

В этом посте я обосную мнение, что хотя ООП и ФП ортогональны, это не взаимно исключающие понятия. Что хорошая функциональная программа может (и должна) быть объектно ориентированной. И что хорошая объектно ориентированная программа может (и должна) быть функциональной. Но для того, чтобы это сделать, нам придётся определиться с терминами.

Что такое ООП?

Я подойду к вопросу с редукционистских позиций. Есть много правильных определений ООП которые покрывают множество концепций, принципов, техник, паттернов и философий. Я намерен проигнорировать их и сосредоточиться на самой соли. Редукционизм тут нужен из-за того, что всё это богатство возможностей, окружающее ООП на самом деле не является чем-то специфичным для ООП; это просто часть богатства возможностей встречающихся в разработке программного обеспечения в целом. Тут я сосредоточусь на части ООП, которая является определяющей и неустранимой.

Посмотрите на два выражения:

Никакой семантической разницы явно нет. Вся разница целиком и полностью в синтаксисе. Но одно выглядит процедурным, а другое объектно ориентированным. Это потому что мы привыкли к тому, что для выражения 2. неявно подразумевается особая семантика поведения, которой нет у выражения 1. Эта особая семантика поведения — полиморфизм.

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

С другой стороны, когда мы видим выражение 2. мы видим объект с именем o которому посылают сообщение с именем f. Мы ожидаем, что могут быть другие виды объектов, котоые принимают сообщение f и поэтому мы не знаем, какого конкретно поведения ожидать от f после вызова. Поведение зависит от типа o. то есть f — полиморфен.

Вот этот факт, что мы ожидаем от методов полиморфного поведения — суть объектно ориентированного программирования. Это редукционистское определение и это свойство неустранимо из ООП. ООП без полиморфизма это не ООП. Все другие свойства ООП, такие как инкапсуляция данных и методы привязанные к этим данным и даже наследование имеют больше отношения к выражению 1. чем к выражению 2.

Программисты, использующие Си и Паскаль (и до некоторой степени даже Фортран и Кобол) всегда создавали системы инкапсулированных функций и структур. Чтобы создать такие структуры даже не нужен объектно ориентированный язык программирования. Инкапсуляция и даже простое наследование в таких языках очевидны и естественны. (В Си и Паскале более естественно, чем в других)

Поэтому то, что действительно отличает ООП программы от не ООП программ это полиморфизм.

Возможно вы захотите возразить, что полифорфизм можно сделать просто используя внутри f switch или длинные цепочки if/else. Это правда, поэтому мне нужно задать для ООП ещё одно ограничение.

Использование полиморфизма не должно создавать зависимости вызывающего от вызываемого.

Чтобы это объяснить, давайте ещё раз посмотрим на выражения. Выражение 1: f(o), похоже зависит от функции f на уровне исходного кода. Мы делаем такой вывод потому что мы также предполагаем, что f только одна и что поэтому вызывающий должен знать о вызываемом.

Однако, когда мы смотрим на Выражение 2. o.f() мы предполагаем что-то другое. Мы знаем, что может быть много реализаций f и мы не знаем какая из этих функций f будет вызвана на самом деле. Следовательно исходный код, содержащий выражение 2 не зависит от вызываемой функции на уровне исходного кода.

Если конкретнее, то это означает, что модули (файлы с исходным кодом), которые содержат полиморфные вызовы функций не должны ссылаться на модули (файлы с исходным кодом), которые содержат реализацию этих функций. Не может быть никаких include или use или require или каких-то других ключевых слов, которые создают зависимость одних файлов с исходным кодом от других.

Итак, наше редукционистское определение ООП это:

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

Что такое ФП?

И опять я буду использовать редукционистский подход. У ФП есть богатые традиции и история, корни которых глубже, чем само программирование. Существуют принципы, техники, теоремы, философии и концепции, которыми пронизана эта парадигма. Я всё это проигнорирую и перейду сразу к самой сути, к неотъемлемому свойству которое отделяет ФП от других стилей. Вот оно:

f(a) == f(b) если a == b.

В функциональной программе вызов функции с тем же аргументом даёт тот же результат независимо от того, как долго работала программа. Это иногда называют референциальной прозрачностью.

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

У этого есть и более глубокое следствие — ни одно именованное значение нельзя менять. То есть оператора присваивания нет.

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

Фокус, конечно, в рекурсии. Рассмотрим функцию которая принимает структуру с состоянием в качестве аргумента. Этот аргумент состоит из всей информации о состоянии, которая нужна функции для работы. Когда работа окончена, функция создаёт новую структуру с состоянием, содержимое которой отличается от предыдущей. И последним действием функция вызывает саму себя с новой структурой в качестве аргумента.

Это только один из простых трюков, которые фукциональная программа может использовать чтобы хранить изменения состояния без необходимости изменять состояние [1].

Итак, редукционистское определение функционального программирования:

Референциальная Прозрачность — переприсваивать значения нельзя.

ФП против ООП

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

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

Но ортогональность не подразумевает взаимного исключения (спросите Джеймса Клерка Максвелла). Вполне можно создать систему, которая использует и динамический полиморфизм и референциальную прозрачность. Это не только возможно, это правильно и хорошо!

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

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

Главная мысль тут такая:

Нет никакого холивара ФП против ООП

ФП и ООП хорошо работают вместе. И то и другое хорошо и правильно использовать в современных системах. Система, которая построена на комбинации принципов ООП и ФП максимизирует гибкость, поддерживаемость, тестируемость, простоту и прочность. Если убрать одно ради добавления другого это только ухудшит структуру системы.

[1] Так как мы используем машины с архитектурой Фон Неймана мы предполагаем, что в них есть ячейки памяти, состояние которых на самом деле изменяется. В механизме рекурсии, который я описал, оптимизация хвостовой рекурсии не даст создавать новые стекфреймы и будет использоваться первоначальный стекфрейм. Но это нарушение референциальной прозрачности (обычно) скрыто от программиста и ни на что не влияет.

  • Программирование
  • Java
  • Совершенный код
  • Функциональное программирование

Функциональное и объектно-ориентированное программирование

Достоинства функционального программирования (ФП) и объектно-ориентированного программирования (ООП) — предмет нескончаемых дебатов на любом техническом онлайн форуме. Хоть и трудно однозначно сказать, какое программирование лучше, их всегда можно сравнить и понять, который из двух больше подходит для разработки ваших приложений.

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

Объектно-ориентированное программирование

ООП — это парадигма, в основе которой лежит идея “объектов”. Объекты содержат данные в виде полей и код. Поля также известны под названием «атрибуты», а код в форме процедур, часто называют «методами». Объединяя данные и связанное с ними поведение в один «объект», объектно-ориентированное программирование облегчает понимание того, как работает программа.

Объектно-ориентированное программирование основывается на четырех ключевых принципах:

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

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

Функциональное программирование

ФП — это процесс создания программного обеспечения путем использования чистых функций. Все объекты в ФП неизменяемы. Это означает, что как только что-то создано, оно не может быть изменено. В функциональном программировании данные и поведение — это разные сущности. Следовательно, они должны храниться отдельно друг от друга для ясности кода.

ФП основывается на шести концепциях:

  • функции высшего порядка (HOF);
  • чистая функция;
  • рекурсия;
  • ссылочная прозрачность.
  • строгая и ленивая оценка;
  • системы типов.

Плюсы и минусы объектно-ориентированного программирования

Плюсы

Программисты часто выбирают ООП подход. Все потому что он помогает обезопасить программы от несанкционированного доступа. Он скрывает переменные внутри класса и, таким образом, предотвращает доступ извне. Кроме того, в ООП есть возможность использовать модульность (возможность разделения функциональности программы на независимые модули) и управлять общими состояниями кода.

Объекты можно легко повторно задействовать в других приложениях. Создание новых объектов для того же класса не вызывает трудностей, а сам код легко изменять и поддерживать в актуальном состоянии.

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

Минусы

ООП нельзя использовать повторно. Поскольку некоторые функции зависят от класса, который их использует и их нельзя применять в другом классе. Кроме того, ООП менее эффективен и с ним сложнее справляться. Многие объектно-ориентированные программы созданы для моделирования массивных архитектур и могут быть сложными.

Плюсы и минусы функционального программирования

Плюсы

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

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

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

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

Минусы

ФП тесно связан с манипулированием данными, а для написания кода требуется другой подход. При преобразовании реального сценария в код, намного проще мыслить ОО категориями. В ФП, такие преобразования потребуют больше умственных усилий.

Поскольку ФП сложнее в освоении, чем ООП, не каждый программист выберет этот подход. Следовательно, в интернете меньше информации по теме.

Функциональное Программирование или ООП: Что лучше?

Очевидно, что для ООП программистов ООП — это лучший подход к разработке программного обеспечения. Между тем ФП приверженцы отстаивают право ФП в программировании.

В то же время объектно-ориентированное программирование и функциональное программирование являются важными парадигмами, которые преследуют одинаковую цель — разработка понятных программ без ошибок.

ООП объединяет данные и связанное с ними поведение в объект. Это помогает программистам легче понять, как работает программа, хотя код намного длиннее, чем в ФП.

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

Разработчики программного обеспечения любят сравнивать эти две концепции. Например, на Stack Overflow Норман Рэмси, профессор Тафтса и исследователь языков программирования, определил проблему выбора одной концепции в пользу другой следующим образом:

  • ООП отлично работает, когда поведение программы четко определено, но типы данных меняются;
  • ФП лучше подходит, когда все объекты понятны, но поведение может измениться.

Хотя ООП и ФП — это две совершенно разные концепции, это не означает, что они взаимоисключают друг друга. Эти два метода могут быть эффективно использованы в одном исходном коде разрабатываемого приложения.

Когда разработчики программного обеспечения объединяют ООП и ФП в своих процессах разработки, они могут создавать гибкие, высокопроизводительные, простые в обслуживании и тестировании решения.

Заключение

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

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

Когда применять функциональное программирование, а когда ООП — отвечают эксперты

ООП или функциональное программирование? А может, всё сразу? Узнаём у экспертов, когда нужно применять ту или иную парадигму программирования.

Многие слышали про функциональное программирование и, возможно, задавались вопросом: «А зачем оно, когда есть ООП?». Мы спросили у экспертов, когда стоит использовать ту или иную парадигму.

Аватарка эксперта Михаил Головатый

Михаил Головатый
ведущий разработчик блока Инновационных решений группы компаний «Лига Цифровой Экономики»

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

Объектно-ориентированное программирование (ООП) является более «традиционной» парадигмой. С её помощью разработано несчётное количество программ, в том числе огромные промышленные системы в финансовых организациях, телекоммуникации на производстве, складах, транспорте. Незнание принципов ООП фактически перекроет доступ ко всем этим системам.

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

Что касается функционального программирования (ФП). В каком-то сильно упрощённом виде оно используется и при ООП — в школах первые программы пишут функциями. С него нужно начинать изучение языков программирования, им же и завершать. Далее, в зависимости от нужд конкретного проекта, можно углублять знания той парадигмы, которая больше используется. Парадигма ФП влияет и на программирование, и на проектирование программного обеспечения. Для высоконагруженных систем переход к обработке потоков данных может быть спасением. Для выбора этой парадигмы в «большой» системе как минимум нужно иметь много данных и большую нагрузку (много вызовов, много пользователей). С одной стороны, она может дистанцировать бизнес-модель от реализации, с другой — позволит вовремя отвечать на запросы пользователей и иных внешних систем. Для небольших программ выбор ФП возможен, тут больше дело вкуса. Однако новичку может быть непросто разделить бизнес-модель на данные и потоки данных и спроектировать так, чтобы данные не хранились в классах и было чистое ФП.

Что выбрать новичку для изучения?

Изучить всё сразу не получится, но для быстрого старта карьеры, на мой взгляд, достаточно знать принципы ООП и иметь хотя бы общее представление о функциональных, процедурных языках: современные подходы используют некоторые более старые парадигмы, в новой реализации они могут быть очень эффективны. Если есть поверхностное знание о функциональном программировании — это вообще замечательно. Значит, у разработчика есть выбор, меньше ограничений на реализацию задуманного.

Аватарка эксперта Николай Андрюхин

Николай Андрюхин
frontend-разработчик IT-компании MediaSoft

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

ООП-подход подразумевает написание базовых классов и расширение существующих путем добавления к ним методов. Данные хранятся в экземпляре класса вместе с методами, которые ими оперируют. Функции в ООП зависят от внешних данных (например содержат внутри себя ссылки на глобальные переменные) или коммуницируют с внешним миром (ввод-вывод).

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

Но эти подходы не являются взаимоисключающими. Нет необходимости выбирать только одну парадигму и следовать ей до конца. Вы можете передавать классы в чистые (то есть не связанные с внешними данными) функции или можете использовать чистые функции в качестве методов класса — одно другому не противоречит, а только дополняет. Если вы пишете простую и небольшую программу, следование той или иной парадигме — сугубо ваше личное мнение и видение прекрасного. Однако если вы пишете большой сервис с разноплановыми задачами, в определённый момент вы столкнетесь с необходимостью рефакторинга, так как для эффективного решения всех этих задач одного подхода будет недостаточно.

Приведу пример. Если вы пишете на Node.js, на первый взгляд удобнее использовать ФП. Дело в том, что сам по себе запрос на сервер — это функция с определённым входом и выходом (request, response). А работа с request’ом происходит с помощью цепочки функций (middleware), и результат (response) всегда будет одинаковый, если в качестве аргументов передавать одни и те же значения. Функциональный подход здесь смотрится естественно. С другой стороны, если Node.js-сервис подразумевает работу с БД, для описания моделей и работы с ними удобнее применить ООП-подход. Примером служит популярная библиотека sequelize.

На просторах frontend особой популярностью пользуются фреймворки, и каждый из них использует ту или иную парадигму, но для полноценной работы с ними необходимо знание как ООП, так и ФП. Взять для примера Angular: данный фреймворк построен на сервисах, которые в свою очередь являются классами, содержащими данные и методы для работы с ними. Однако при работе с библиотекой Redux, обычно работающей в паре с React, напрямую сталкиваешься с функциональным подходом, так как основная идея Redux — использование чистых функций без побочных эффектов.

Аватарка эксперта Максим Стегниенко

Максим Стегниенко
ведущий iOS-разработчик в FINCH

ООП vs. ФП — вечная дилемма. Мне кажется, что наибольшей эффективности в разработке можно добиться, только если миксовать подходы. Точно не стоит писать проект только на ФП, потому что такой подход сильно ограничивает разработку: нужно постоянно прорабатывать поведение state.

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

Всегда стоит думать о логике проекта. Если в приложении много динамики, то архитектура REST API из функционального программирования отлично сработает, так делают те же ребята из tutu.ru. То же самое работает и наоборот — если у вас обычное сервисное приложение, где пользователю отображают JSON, то особо смысла использовать ФП нет.

Аватарка эксперта Виталий Мосейко

Виталий Мосейко
старший инженер-программист практики Java компании «Рексофт»

«Когда применять функциональное программирование, а когда ООП?» — вопрос совсем непростой. Если посмотреть форумы, то понятно, что холивар возникает уже на этапе самого определения функционального программирования.

Если исходить из определения, что функциональный стиль — это когда результат выполнения кода всегда зависит только от поданных на вход значений, то лично я такой подход стараюсь применять как можно чаще. Это упрощает читабельность кода, его тестирование. Однако ФП более характеризуется тем, что аргументами одних функций являются другие, более простые функции, и вот это наиболее сложная часть, где можно легко выскочить за сложность вычислений O(n).

Не очень понятно, как сравнить ООП и функциональное программирование (ФП). Я считаю, что модели могут тесно пересекаться, не исключая друг друга, и где какую модель применять, зависит от архитектуры программы и задач, стоящими перед каждым модулем программы. Например ваш код имитирует движение транспортного средства (ТС). Нужно каждую секунду вычислять координаты ТС, его скорость, пройденный путь. Для того, чтобы это сделать, необходимо будет производить вычисления на основе предыдущих вычислений. Если применить функциональное программирование, то появляется необходимость хранения результатов вычислений и подачи их каждый раз на вход модели. Это создаст дополнительные логические сложности, поэтому в этой задаче лучше скомбинировать ООП и ФП. Для каждого ТС создаётся объект в стиле ООП, и каждый объект сам хранит свои предыдущие вычисления. Вам остаётся на вход подавать только ускорение, направление движения и время, в течение которого они действовали. Внутри же объекта ТС у вас будет два десятка методов, рассчитывающих его новое состояние. И вот тут рекомендация: стремиться большую часть из них сделать в виде простых функций, и только в одном или двух в вычисления добавить влияние его предыдущего состояния или используемого набора функций.

Сейчас порог входа в программисты очень высок, и изучать что-то одно и быть востребованным у программиста вряд ли получится.

Итак, какую парадигму выбрать?

ООП-подход подразумевает написание базовых классов и расширение существующих путем добавления к ним методов. Данные хранятся в экземпляре класса вместе с методами, которые ими оперируют. Функции в ООП зависят от внешних данных.

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

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

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

Что до новичков, то определённо стоит изучить ООП, так как это более «традиционная» парадигма, которая много где используется. Но стоит иметь хотя бы общее представление о ФП, чтобы иметь у себя в арсенале ещё один инструмент.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Функциональное и императивное программирование (LINQ to XML)

В этой статье сравнивается функциональное программирование с более традиционным императивным (процедурным) программированием.

Функциональное и императивное программирование

Принципы функционального программирования формулировались специально для поддержки чисто функционального подхода к решению проблем. Функциональное программирование является одной из форм декларативного программирования. В отличие от этого, большинство традиционных языков, в том числе такие языки объектно-ориентированного программирования (OOP), как C#, Visual Basic, C++ и Java, разрабатывались в основном для императивного (процедурного) программирования.

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

Характеристика Императивный подход Функциональный подход
Основная направленность усилий программиста Способы выполнения (алгоритмы) задач и отслеживания изменений в их состоянии. Требуемые данные и преобразования.
Изменения состояния Важно! Не существует.
Порядок выполнения Важно! Низкая значимость.
Управление основным потоком данных Циклы, условия и вызовы функций (методов). Вызовы функций, включая рекурсивные.
Основная единица обработки Экземпляры структур или классов. Функции как полноценные объекты и коллекции данных.

Безусловно, большинство языков программирования было разработано в целях поддержки определенных подходов к программированию, но многие языки общего назначения являются достаточно гибкими, чтобы поддерживать несколько подходов. Например, большинство языков, содержащих указатели на функции, могут использоваться для надежной поддержки функционального программирования. Кроме того, C# и Visual Basic включают явные расширения языка для поддержки функционального программирования, включая лямбда-выражения и вывод типов. Одной из форм декларативного, функционального программирования является технология LINQ.

Функциональное программирование с использованием XSLT

Многие разработчики XSLT знакомы с чисто функциональным подходом. Наиболее эффективный способ разработки таблицы стилей XSLT состоит в том, что каждый шаблон рассматривается как изолированное, составное преобразование. При этом совершенно не приходится задумываться над тем, в каком порядке должны проводиться вычисления. XSLT не допускает побочных эффектов (за исключением того, что экранирование механизмов для выполнения процедурного кода может привести к возникновению побочных эффектов, которые приводят к функциональной нечистоте). Тем не менее, хотя XSLT является эффективным инструментом, некоторые из его характеристик не являются оптимальными. Например, программные конструкции приходится представлять на языке XML, в связи с чем объем кода становится довольно большим, поэтому его сопровождение затрудняется. Кроме того, большая зависимость от рекурсии для управления потоком может привести к тому, что код будет трудно читать. Дополнительные сведения об XSLT см. в разделе Преобразования XSLT.

Тем не менее XSLT доказал свою полезность при чисто функциональном подходе для преобразования XML из одного вида в другой. Чисто функциональное программирование с помощью LINQ to XML во многом похоже на XSLT. Однако конструкции программирования, представленные LINQ to XML, C# и Visual Basic, позволяют создавать чистые функциональные преобразования, которые являются более удобочитаемыми и обслуживаемыми, чем XSLT.

Преимущества чистых функций

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

  • Повышенная удобочитаемость и обслуживаемость. Это объясняется тем, что каждая функция разрабатывается для выполнения конкретных задач, определяемых аргументами. Функция не зависит от внешнего состояния.
  • Упрощается разработка, основанная на ранее созданном коде. Код становится более приемлемым для оптимизации кода, поэтому легче реализовать изменения в проекте. Например, предположим, что в процессе написания сложного преобразования выясняется, что какой-то код повторяется несколько раз. Если оптимизация кода предусматривает преобразование в чистый метод, то полученный чистый метод можно вызывать в любое время, не беспокоясь о побочных эффектах.
  • Упрощаются тестирование и отладка. Чистые функции проще тестировать отдельно от основной части кода, поэтому можно написать проверочный код, в котором чистая функция вызывается с типичными значениями, допустимыми краевыми значениями и недопустимыми краевыми значениями.

Переход для разработчиков ООП

Традиционное объектно-ориентированное программирование (OOP) является таковым, что большинство разработчиков привыкает писать код в императивном (процедурном) стиле. Переходя к разработке в чисто функциональном стиле, они должны изменить свое мышление и подход к разработке.

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

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

К счастью, для C# и Visual Basic не требуется полный переход к функциональному программированию, так как они поддерживают как императивные, так и функциональные подходы к программированию. Разработчик может сам выбирать нужный подход в зависимости от конкретного сценария. В действительности в программах часто сочетаются оба стиля.

См. также

  • Введение в чистые функциональные преобразования
  • Преобразования XSLT
  • Рефакторинг в чистые функции

Совместная работа с нами на GitHub

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *