Задать вопрос

Для чего существуют другие парадигмы программирования?

Господа, обьясните используются ли в коммерческих приложениях какие либо парадигмы помимо ООП и процедурной?
Процедурная была на сколько я понимаю первой, где программа писалась по нисходящей, и ее выполнение происходило строка за строкой, и судя по википедии отражала архитектуру самой ЭВМ, которая последовательно приводит входные данные к конечным. ООП удобен для бизнеса, можно разделять программу на модули, инкапсулировать код, полиморфизм предоставит повторное использование, что сократит затраты. А для чего нужно еще столько парадигм? Например для какой такой задачи нужно использовать АОП(агентно ориентированный подход)?
  • Вопрос задан
  • 2348 просмотров
Подписаться 8 Простой Комментировать
Решения вопроса 1
saboteur_kiev
@saboteur_kiev Куратор тега Программирование
software engineer
Нельзя в двух словах сказать зачем нужны парадигмы программирования, потому что для этого нужно иметь опыт программирования, чтобы вы могли усвоить ответ.

Например, ваше представление: "ООП удобен для бизнеса, можно разделять программу на модули" - неверно.
Модульность появилась задолго до ООП. Бизнес появился задолго до программирования, и ООП и бизнес не слишком и связаны.

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

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

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

И напоследок - полиморфизм и все другие фичи ООП - это уже следствие того, что парадигму стараются сделать максимально гибкой.
Самая главная суть ООП заключается в следующем:

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

Так достигается высокая совместимость, упрощается миграция со старых версий в очень зависимых проектах и такая парадигма позволяет очень легко распарралелить процесс разработки.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 6
lxsmkv
@lxsmkv
Test automation engineer
Любую программу можно написать с любым подходом. Разница лишь в том, насколько удобно будет моделировать законы реального мира в программе. ООП потому распространено, что провести аналогию между программным обьектом и обьектом из реального мира очень легко. При программировании предметных областей которые не имеют осязаямых участников, могут быть удобны другие парадигмы. По той же причине когда нужно в ООП отображать неосязаемые сущности, могут возникать определенные сложности с именованием классов. Может замечали. Не все рифмуется в эту парадигму. Иногда вам нужны просто вычисления, тогда декомпозиция задачи на объекты не нужна совсем.
Парадигма это всего лишь перспектива взгляда на одно и то же. В зависимости от того с какой стороны мы смотрим на предмет, очередность (приоритет) компонент его составляющих для зрителя будет меняться. В какой-то задаче может быть важно время, а в какой-то цвет, а в какой-то измерение. Что является единицей анализа в честь того и парадигма.
Ответ написан
Комментировать
@iKest
Функциональная парадигма - haskell, scala
Прототипно-ориентированная парадигма - js
Ответ написан
@AnneSmith
самая ленивая
ООП вы не напишете без процедурного, а АОП - без ООП
википедия пишет, что АОП - это частный случай ООП

АОП - это тот же ООП, но управляемый событиями, а не вручную, как делают в обычном ООП

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

в АОП более абстрактный уровень классов типа item/asset/widget, а "клиенты, продукты, машины" являются не классами, а свойствами, или часто там совсем другие типы классов,

когда у вас есть один и тот же класс, то нет проблемы несовместимых интерфейсов, и все делается программно, управляется событиями, вместо того чтобы вручную писать какой должен быть найден объект и что конкретно в каждый момент он должен делать
Ответ написан
@Veselina
Если говорить о языках программирования, то Kotlin поддерживает объектно-ориентированный и функциональный подходы програмииовния, что очень и очень удобно.
Ответ написан
Комментировать
@JustMoose
Программист. Радиолюбитель. Прокрастинатор ;)
В старые добрые времена было ещё функциональное и логическое программирование.
Функциональное - лисп. Логическое - пролог.
Про лисп ничего толком не скажу (вроде бы там ожидалось получение профита при замене циклов рекурсией и т.п.). А вот логическое программирование, имхо, интересно "концепцией". Если все современные языки выливаются в некоторое последовательное выполнение кода, то в логических языках были некие "правила". И порядок их выполнения выбирался "ядром". В результате процесс выполнения сводился к поиску набора правил, последовательное применение которых дало бы нужное решение. В общем, интересная штука ;) (Правда, малопонятная и, имхо, слабоприменимая).
https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D...
Ответ написан
Комментировать
@pharo
Из парадигм программирования можно ещё упомянуть для рассмотрения конкатенативное программирование и языки относимые к явному использованию её https://concatenative.org

Самый известный и первый язык практического конкатенативного программирования Forth (Форт) до сих пор используется для создания разного ПО, но особенно представителен в нише программирования встроенных систем.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы