В чем суть процедурного программирования?

Question

[alex4answ]

Добрый день, года 3 я пишу только в ООП стиле, очень редко приходится что-то накидать в процедурном стиле, что-то маленькое и по быстрому

Не понимаю, в чем плюсы и как вообще можно сравнивать процедурный стиль с ООП

Подскажите пожалуйста, зачем отказываться от ООП в пользу другого ?

Comments

[alex4answ]

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

[Денис Загаевский]

Dr. Bacon, откуда такой диагноз?

Answer 1

[Victor Bomberow]

alex4answ, процедурный стиль использует только понятия модель памяти, типы, инструкции, программа и подпрограмма.

Вот и всё. Никаких составных типов. Концепция "состояние" в коде никак не выражается. Держите её если хотите в голове либо в комментариях.

Никаких сущностей в коде. Держите из в голове или в комментариях.

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

Но это всё уже вводится в структурном программировании.

Процедурное программирование вводит модель памяти с понятиями стек и куча. Хотите сделать функцию в процедурной парадигме - вам придется оформить её в виде подпрограммы и вызывать её из другой. Причем понятия линковки нет, вы будете делать это используя адрес в куче, а какие-то данные, типа, аргументы, будете сами на стэк ложить, каждый раз при вызове подпрограммы "функция".
Ах, да, захотите функцию для сложения двух чисел, придется сделать ctrl-c, ctrl-v и в теле подпрограммы написать сложение двух кусков данных взятых со стека. Для разности - копируете код, в теле меняете инструкции. И так для каждой функции.

Да, понятия область видимости нет, придется его выражать в коде таким вот образом самостоятельно.

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

А максимум абстрагирования, которое вводит процедурное программирование, это символьное произвольное именование адреса в памяти. Да и вместо типов, скорее, используется смещение байтов для коллекции, которым просто даны имена.

Дело в том, что о процедурной парадигме можно говорить только ретроспективно. В основном, процедурная парадигма это классический ассемблер.

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

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

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

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

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

Answer 2

[koperagen]

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

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

Answer 3

[res2001]

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

Answer 4

[Kosika]

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

Вот примеры кодов на PHP, выводящих "Hello, world!", написанных в процедурном и ОО подходах:

• Процедурный подход:
  

<?php
print "Hello, world!";
?>

• ОО подход:
  

<?php
class helloWorld {
function myPrint() {
print "Hello, world!";
}
}
$myHelloWorld = new helloWorld();
$myHelloWorld->myPrint();
?>

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

Answer 5

[Ставр Стрелов]

Это когда ты пишешь просто команды - процедуры. Без классов, методов, все в одном файле и в виде команд)

Comments

[alex4answ]

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

[Андрей Пике]

Ну правильно всё написали.
ASM и классичесий C - то же самое, особенно на дешёвых микроконтроллерах.
Поэтому востребовано при определённой специфике.
Где и памяти-то особо нет. Ни RAM, ни ROM.
(например, Microchip или HT)

Но тот же jQuery, который умирает, тоже процедурный.
Был популярен, ввиду простоты и универсальности в своё время.
Но в web development его уже задавили, конечно.
Остался как костыль.
В нашей компании, по крайней мере. Перешли на Vue.

Answer 6

[АртемЪ]

Не понимаю, в чем плюсы

Вы же сами ответили-

накидать в процедурном стиле, что-то маленькое и по быстрому

Попробуйте по быстрому накидать в ООП.

и как вообще можно сравнивать процедурный стиль с ООП

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

Подскажите пожалуйста, зачем отказываться от ООП в пользу другого ?

Я не в курсе зачем вам это нужно.

Answer 7

[juchkovdavid]

Весь код пишу в поцедурном стиле.
Структура такая:
js/main.js - обработка форм, кнопок, асинхронный вывод html на страницу (полученный запросами к процедурному коду).
post - каталог, содержит файлы *.php, на них и отправляются запросы с форм, кнопок, запрос контента.
на заметку: jquery и другие библиотеки уже не использую, т.к. достаточно наработок на чистом js :)
Я тут один такой?
p.s: на CMS так-же работаю, но структура зависит от CMS. ООП для меня редкость

Comments

[Deadprofessor]

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