ООП против функционального программирования против процедурного

Все они хороши по-своему - просто разные подходы к одним и тем же проблемам.

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

В объектно-ориентированном стиле данные имеют тенденцию нести с собой набор функций.

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

Конечно, сам язык влияет только на то, какой стиль предпочтительнее. Даже на чисто функциональном языке, таком как Haskell, вы можете писать в процедурном стиле (хотя это крайне не рекомендуется), и даже на процедурном языке, таком как C, вы можете программировать в объектно-ориентированном стиле (например, в GTK + и EFL API).

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

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

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

Например, если вы создаете видеоигру, на C ++ есть больше хороших примеров кода и SDK, так что вам, вероятно, будет лучше. Для небольшого веб-приложения есть несколько отличных фреймворков Python, PHP и Ruby, которые помогут вам быстро начать работу. Java - отличный выбор для больших проектов из-за проверки во время компиляции и корпоративных библиотек и платформ.

Раньше стандартные библиотеки для разных языков были довольно маленькими и легко воспроизводились - C, C ++, Assembler, ML, LISP и т. Д. Поставлялись с основами, но имели тенденцию отклоняться, когда дело доходило до стандартизации. такие как сетевая связь, шифрование, графика, форматы файлов данных (включая XML), даже базовые структуры данных, такие как сбалансированные деревья и хэш-таблицы, были исключены!

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

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

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

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

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

То же самое и с ООП. Такой язык, как Java, не позволяет писать процедуры / функции вне класса. Единственный способ передать функцию - обернуть ее в объект, реализующий эту функцию, а затем передать этот объект.

В Python этого ограничения нет.

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

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

Чтобы ответить на ваш вопрос, нам понадобятся два элемента:

1. Понимание характеристик различных архитектурных стилей / паттернов.
2. Понимание характеристик различных парадигм программирования.

Список стилей / шаблонов архитектуры программного обеспечения показан в статье об архитектуре программного обеспечения на сайте Wikipeida. И вы можете легко найти их в Интернете.

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

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

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

Я думаю, что они часто не «против», но их можно комбинировать. Я также думаю, что часто слова, которые вы произносите, являются просто модными словечками. Немногие люди действительно знают, что означает «объектно-ориентированный», даже если они самые яростные его проповедники.

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

а) Вы разрабатываете умную систему, которая в определенной степени имитирует наследование. Это можно сделать!

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

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

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

б) Вы можете использовать последовательную политику именования и использовать подход разделяй и властвуй для создания программы. У него не будет никакого наследования, но поскольку ваши функции небольшие, легкие для понимания и единообразно отформатированы, они вам не нужны. Объем кода, который вам нужно написать, увеличивается, очень сложно оставаться сосредоточенным и не поддаваться легким решениям (хакам). Однако этот способ кодирования ниндзя - это способ кодирования C. Сохранение баланса между свободой на низком уровне и написанием хорошего кода. Хороший способ добиться этого - написать прототипы с использованием функционального языка. Например, Haskell очень хорош для создания прототипов алгоритмов.

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