в чем преимущества ооп перед процедурным программированием

Что такое процедурное программирование?

Что такое процедурное программирование?

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

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

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

Передача параметров: Передача параметров — это механизм, используемый для передачи параметров в функции, подпрограммы или процедуры. Передача параметров может быть выполнена через «передача по значению», «передача по ссылке», «передача по результату», «передача по значению-результату» и «передача по имени».

Преимущества и недостатки процедурного программирования

Процедурное программирование имеет свои плюсы и минусы, некоторые из которых упомянуты ниже.
Преимущества

Недостатки

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

Что такое объектно-ориентированное программирование (ООП)

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

Недостатки

Процедурное программирование против объектно-ориентированного программирования: сравнение между собой

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

Недостатки

Вывод

Как мы уже говорили в этой статье, процедурное программирование — это больше, чем вы делаете, а не то, как вы это делаете. Это стандартный подход, используемый во многих компьютерных языках, таких как C, Pascal и BASIC. Хотя идеальной парадигмы программирования не существует, важно понимать, что правильная парадигма всегда будет зависеть от типа используемого вами языка и программы, которую вы хотите создать. Рекомендуется, чтобы для достижения максимальных результатов и сильного портфеля, нужно было владеть всеми тремя основными парадигмами программирования. Лучший способ попытаться стать лучше в программировании — это, конечно пройти курсы программирования.

Источник

«Забытые» парадигмы программирования

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

Ладно. Введение это очень весело, но вы его все равно не читаете, так что кому интересно — добро пожаловать под кат!

Императивное программирование

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

Это были машинные коды, языки ассемблера и ранние высокоуровневые языки, вроде Fortran.

Ключевые моменты:

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

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

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

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

Основные понятия:

Порожденные понятия:

— Присваивание
— Переход
— Память
— Указатель

Языки поддерживающие данную парадигму:

Как основную:

— Языки ассемблера
— Fortran
— Algol
— Cobol
— Pascal
— C
— C++
— Ada

Как вспомогательную:

— Python
— Ruby
— Java
— C#
— PHP
— Haskell (через монады)

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

Структурное программирование

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

Основоположниками структурного программирования были такие знаменитые люди как Э. Дейкстра и Н. Вирт.

Языками-первопроходцами в этой парадигме были Fortran, Algol и B, позже их приемниками стали Pascal и C.

Ключевые моменты:

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

В структурном программировании мы по прежнему оперируем состоянием и инструкциями, однако вводится понятие составной инструкции (блока), инструкций ветвления и цикла.

Благодаря этим простым изменениям возможно отказаться от оператора goto в большинстве случаев, что упрощает код.

Иногда goto все-же делает код читабельнее, благодаря чему он до сих пор широко используется, несмотря на все заявления его противников.

Основные понятия:

— Блок
— Цикл
— Ветвление

Языки поддерживающие данную парадигму:

Как основную:

Как вспомогательную:

— C#
— Java
— Python
— Ruby
— JavaScript

Поддерживают частично:
— Некоторые макроассемблеры (через макросы)

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

Процедурное программирование

Опять-же возрастающая сложность программного обеспечения заставила программистов искать другие способы описывать вычисления.

Собственно еще раз были введены дополнительные понятия, которые позволили по-новому взглянуть на программирование.

Этим понятием на этот раз была процедура.

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

Ключевые моменты:

Процедура — самостоятельный участок кода, который можно выполнить как одну инструкцию.

В современном программировании процедура может иметь несколько точек выхода (return в C-подобных языках), несколько точек входа (с помощью yield в Python или статических локальных переменных в C++), иметь аргументы, возвращать значение как результат своего выполнения, быть перегруженной по количеству или типу параметров и много чего еще.

Основные понятия:

Порожденные понятия:

— Вызов
— Аргументы
— Возврат
— Рекурсия
— Перегрузка

Языки поддерживающие данную парадигму:

Как основную:

— C
— C++
— Pascal
— Object Pascal

Как вспомогательную:

— C#
— Java
— Ruby
— Python
— JavaScript

Поддерживают частично:
— Ранний Basic

Стоит отметить, что несколько точек входа из всех этих языков поддерживаются только в Python.

Модульное программирование

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

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

Программа описанная в стиле модульного программирования — это набор модулей. Что внутри, классы, императивный код или чистые функции — не важно.

Благодаря модулям впервые в программировании появилась серьезная инкапсуляция — возможно использовать какие-либо сущности внутри модуля, но не показывать их внешнему миру.

Ключевые моменты:

Модуль — это отдельная именованная сущность программы, которая объединяет в себе другие программные единицы, близкие по функциональности.

Например файл List.mod включающий в себя класс List
и функции для работы с ним — модуль.

Папка Geometry, содержащая модули Shape, Rectangle и Triangle — тоже модуль, хоть и некоторые языки разделяют понятие модуля и пакета (в таких языках пакет — набор модулей и/или набор других пакетов).

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

Основные понятия:

Порожденные понятия:

Языки поддерживающие данную парадигму:

Как основную:

— Haskell
— Pascal
— Python

Как вспомогательную:

— Java
— C#
— ActionScript 3

Поддерживают частично:
— C/C++

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

Вместо заключения

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

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

Источник

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

Статья не мальчика, но мужа.

Настало время серьёзных тем: сегодня расскажем про объектно-ориентированное программирование, или ООП. Это тема для продвинутого уровня разработки, и мы хотим, чтобы вы его постигли.

Из этого термина можно сделать вывод, что ООП — это такой подход к программированию, где на первом месте стоят объекты. На самом деле там всё немного сложнее, но мы до этого ещё доберёмся. Для начала поговорим про ООП вообще и разберём, с чего оно начинается.

Обычное программирование (процедурное)

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

Например, в интернет-магазине может быть функция «Проверить email». Она получает на вход какой-то текст, сопоставляет со своими правилами и выдаёт ответ: это правильный электронный адрес или нет. Если правильный, то true, если нет — то false.

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

Что не так с процедурным программированием

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

Например, вы пишете функцию «Зарегистрировать пользователя интернет-магазина». Внутри неё вам нужно проверить его электронный адрес. Вы вызываете функцию «Проверить email» внутри функции «Зарегистрировать пользователя», и в зависимости от ответа функции вы либо регистрируете пользователя, либо выводите ошибку. И у вас эта функция встречается ещё в десяти местах. Функции как бы переплетены.

Тут приходит продакт-менеджер и говорит: «Хочу, чтобы пользователь точно знал, в чём ошибка при вводе электронного адреса». Теперь вам нужно научить функцию выдавать не просто true — false, а ещё и код ошибки: например, если в адресе опечатка, то код 01, если адрес спамерский — код 02 и так далее. Это несложно реализовать.

Вы залезаете внутрь этой функции и меняете её поведение: теперь она вместо true — false выдаёт код ошибки, а если ошибки нет — пишет «ОК».

И тут ваш код ломается: все десять мест, которые ожидали от проверяльщика true или false, теперь получают «ОК» и из-за этого ломаются.

Задача, конечно, решаемая за час-другой.

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

Это называется спагетти-код, и для борьбы с ним как раз придумали объектно-ориентированное программирование.

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

Основная задача ООП — сделать сложный код проще. Для этого программу разбивают на независимые блоки, которые мы называем объектами.

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

Программисты договорились, что данные внутри объекта будут называться свойствами, а функции — методами. Но это просто слова, по сути это те же переменные и функции.

Объект можно представить как независимый электроприбор у вас на кухне. Чайник кипятит воду, плита греет, блендер взбивает, мясорубка делает фарш. Внутри каждого устройства куча всего: моторы, контроллеры, кнопки, пружины, предохранители — но вы о них не думаете. Вы нажимаете кнопки на панели каждого прибора, и он делает то, что от него ожидается. И благодаря совместной работе этих приборов у вас получается ужин.

Объекты характеризуются четырьмя словами: инкапсуляция, абстракция, наследование и полиморфизм. Если интересно, что это такое, приглашаем в кат:

Инкапсуляция — объект независим: каждый объект устроен так, что нужные для него данные живут внутри этого объекта, а не где-то снаружи в программе. Например, если у меня есть объект «Пользователь», то у меня в нём будут все данные о пользователе: и имя, и адрес, и всё остальное. И в нём же будут методы «Проверить адрес» или «Подписать на рассылку».

Абстракция — у объекта есть «интерфейс»: у объекта есть методы и свойства, к которым мы можем обратиться извне этого объекта. Так же, как мы можем нажать кнопку на блендере. У блендера есть много всего внутри, что заставляет его работать, но на главной панели есть только кнопка. Вот эта кнопка и есть абстрактный интерфейс.

Например, над магазином работают два программиста: один пишет модуль заказа, а второй — модуль доставки. У первого в объекте «заказ» есть метод «отменить». И вот второму нужно из-за доставки отменить заказ. И он спокойно пишет: «заказ.отменить()». Ему неважно, как другой программист будет реализовывать отмену: какие он отправит письма, что запишет в базу данных, какие выведет предупреждения.

Наследование — способность к копированию. ООП позволяет создавать много объектов по образу и подобию другого объекта. Это позволяет не копипастить код по двести раз, а один раз нормально написать и потом много раз использовать.

Например, у вас может быть некий идеальный объект «Пользователь»: в нём вы прописываете всё, что может происходить с пользователем. У вас могут быть свойства: имя, возраст, адрес, номер карты. И могут быть методы «Дать скидку», «Проверить заказ», «Найти заказы», «Позвонить».

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

Идеальные объекты программисты называют классами.

Полиморфизм — единый язык общения. В ООП важно, чтобы все объекты общались друг с другом на понятном им языке. И если у разных объектов есть метод «Удалить», то он должен делать именно это и писаться везде одинаково. Нельзя, чтобы у одного объекта это было «Удалить», а у другого «Стереть».

При этом внутри объекта методы могут быть реализованы по-разному. Например, удалить товар — это выдать предупреждение, а потом пометить товар в базе данных как удалённый. А удалить пользователя — это отменить его покупки, отписать от рассылки и заархивировать историю его покупок. События разные, но для программиста это неважно. У него просто есть метод «Удалить()», и он ему доверяет.

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

Плюсы и минусы ООП

У объектно-ориентированного программирования много плюсов, и именно поэтому этот подход использует большинство современных программистов.

А теперь про минусы:

Что дальше

Впереди нас ждёт разговор о классах, объектах и всём остальном важном в ООП. Крепитесь, будет интересно!

Источник

ООП против процедурного подхода.

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

Введение

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

ООП легче для понимая в том плане, что оно приближено к реальности. Например, на форуме есть участники, верно? Ну так создайте объект member, который будет обслуживать сущность «участник«. Там будут храниться все их данные: имена, фамилии, пароли, методы регистрации, авторизации и многое другое.

Наследование

К примеру, вы можете создать объект User, который, как понятно из названия(еще один плюс ООП), будет отвечать за пользователей. Он будет содержать примерно такие свойства и методы:

login === false) <
return ‘Пользователь вне сети’;
> else <
return ‘Пользователь в сети’;
>
>

public function login() <
if($this->login === false) <
$this->login = true;
> else <
$this->login = false;
>
>
>
?>

У нас есть объект с полями, содержащими логин пользователя и полем, которое показывает, авторизован пользователь или нет. Также у нас есть метод, проверяющий это поле и возвращающий результат, и метод, который авторизует или деавторизует пользователя.

Теперь мы решили создать администратора. Но он ведь тоже обычный пользователь, верно? Да, с чуть большими правами, но все же он просто пользователь. Зачем все это переписывать? Просто унаследуем.

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

Тоже самое можно сказать и про перегрузку методов. Вам не нужно менять ВСЁ, вам нужно лишь поменять часть кода.

Типизация

Вы можете явно указать какой объект должен быть, и никакой другой не пройдет.

Мы явно указали, что в конструктор должен быть передан пользователь, а не что-то другое.

Здесь мы передаем something вместо пользователя и получим ошибку.

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

Если кто-то хочет серъезно изучить ООП, то советую почитать следующую книжку:

В этой книге довольно неплохо рассказывается про то, какие плюсы у ООП, как его правильно использовать и что такое шаблоны проектирования. Дерзайте! Удачи!

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

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

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Комментарии ( 21 ):

Михаил, а я как то на хабре видел статью (ее еще тогда писали разработчики vk), что процедурный код выполняется чуть шустрее ежели ооп. Так ли это?

Что-то с ajax вы преувеличиваете. Никаких сложностей. Все делается в контроллере. Дергаем данные из модели и выводим в виде. Никаких проблем. Даже и не думал, что это так сложно

я обычно делаю класс контроллера, к примеру называю его ajax. и аяксом отправляю пост запросы в /index/name_function в которой уже и подключаю нужные модели и прочее.

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

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

А у меня вот все иначе) Все, кого знаю из веб области, убеждают, что процедурка целесообразнее. Мол привязка клиента, более быстрое исполнение скриптов и т.д.)))

И таки они правы на все 100 Процедурка и целесообразнее и быстрее

так вот. И как ооп`шнику пересесть не процедурку? Миф и не реальность)

Ух ты! Да вы тут чат устроили) Ну, раз пошло такое дело, то выскажу и я свое мнение. Как в статье и написано, плохого или хорошего подхода нет. Если вы пишете скрипт на 10 строк(я утрирую, конечно), то не стоит заморачиваться с ООП. Тогда и скрипт будет быстрее работать и все будет понятно. Однако, если вы собираетесь писать большой портал, где, как сказано выше, будут модули, очень много самого разного функционала и состоять портал будет из ТЫСЯЧ файлов, то тут, конечно, лучше использовать ООП. Особенно, если вы работаете в команде. Но, если вы совсем не понимаете, зачем нужно ООП, пишете все в процедурном стиле и у вас это хорошо получается, то тогда пишите так и дальше. Но хотя бы основы ООП знать все же стоит.

Хорошая статья. У меня к вам вопрос. Я знаю ООП, но не очень хорошо. А сайт создать все-таки хочется. Так вот, стоит ли писать сайт на процедурном походе, а потом, когда очень хорошо освою, переписать на ООП или изучить как следует ООП и писать на нем?

Учи ООП, многие вещи будет корректней программировать с его использованием

Источник