Здравствуйте, Разраб, Вы писали:

Р>В чем принципиальное отличие?

Отличие в "парадигме". ))
В точке взгляда на проблему и в способах её решения.

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

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

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

Но без "окончательно" инкапсуляции (сокрытия) устройства данных, ФП всерьёз не выстрелит.
А стоит только пойти на это — и ФП превратится в ООП. ))

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

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

Здравствуйте, Разраб, Вы писали:

Р>В чем принципиальное отличие?

Отличие в "парадигме". ))
В точке взгляда на проблему и в способах её решения.

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

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

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

Но без "окончательной" инкапсуляции (сокрытия) устройства данных, ФП всерьёз не выстрелит.
А стоит только пойти на это — и ФП превратится в ООП. ))

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

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