it-swarm.com.ru

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

До сих пор я в основном занимался программированием OO и ​​с нетерпением жду изучения функционального языка. Мои вопросы:

  • Когда вы выбираете функциональное программирование, а не объектно-ориентированное?
  • Каковы типичные определения проблем, где функциональное программирование является лучшим выбором?
743
Olivier Lalonde

Когда вы выбираете функциональное программирование, а не объектно-ориентированное?

Когда вы ожидаете другой вид эволюции программного обеспечения:

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

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

Когда эволюция идет не так, у вас есть проблемы:

  • Добавление новой операции в объектно-ориентированную программу может потребовать редактирования многих определений классов для добавления нового метода.

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

Эта проблема была хорошо известна в течение многих лет; в 1998 году Фил Уодлер назвал это "проблемой выражения" . Хотя некоторые исследователи считают, что проблему выражения можно решить с помощью таких языковых функций, как миксины, широко распространенное решение еще не достигло широкого распространения.

Каковы типичные определения проблем, где функциональное программирование является лучшим выбором?

Функциональные языки Excel при манипулировании символьными данными в древовидной форме. Любимый пример - это компиляторы, где исходный и промежуточный языки меняются редко (в основном это одни и те же вещи ), но авторы компиляторов всегда добавляют новые переводы и улучшения кода или оптимизации (новые операции над вещами). Компиляция и перевод в более общем смысле являются "убийственными приложениями" для функциональных языков.

1144
Norman Ramsey

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

Взять к примеру C #. Можно сказать, что это в основном ООП, но существует множество FP концепций и конструкций. Если учесть Linq , наиболее важные конструкции, которые позволяют Linq существовать, функциональны по своей природе: лямбда-выражения .

Другой пример, F #. Вы могли бы сказать, что это в основном FP, но есть много OOP доступных концепций и конструкций. Вы можете определять классы, абстрактные классы, интерфейсы, иметь дело с наследованием. Вы даже можете использовать изменчивость, когда это делает ваш код более понятным или когда это значительно повышает производительность.

Многие современные языки мультипарадигмы.

Рекомендуемые показания

Поскольку я нахожусь в одной лодке (фон ООП, изучаю FP), я бы посоветовал вам некоторые чтения, которые я действительно ценю:

168
Bruno Reis

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

  1. Инкапсуляция, до
    • контролировать мутацию внутреннего состояния
    • предельная связь с внутренним представлением
  2. Подтип, позволяющий:
    • замещение совместимых типов (полиморфизм)
    • грубое средство разделения реализации между классами (наследование реализации)

Функциональное программирование в Haskell или даже в Scala может позволить замену через более общий механизм классов типов. Изменчивое внутреннее состояние либо не рекомендуется, либо запрещено. Инкапсуляция внутреннего представления также может быть достигнута. Смотрите Haskell vs OOP для хорошего сравнения.

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

ОТРЕДАКТИРОВАНО Удалена ссылка на неявные преобразования при обсуждении классов типов. В Scala классы типов кодируются с неявными параметрами, а не преобразованиями, хотя неявные преобразования являются еще одним средством достижения замены совместимых типов.

31
retronym
  1. Если вы находитесь в сильно параллельной среде, тогда полезно чисто функциональное программирование. Отсутствие изменяемого состояния делает параллелизм почти тривиальным. Смотри Эрланг.

  2. В многопарадигмальном языке вам может потребоваться функционально смоделировать некоторые вещи, если наличие изменяемого состояния является обязательной деталью реализации, и, следовательно, FP является хорошей моделью для проблемной области. Например, см. Списки в Python или std.range на языке программирования D. Они вдохновлены функциональным программированием.

23
dsimcha