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

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

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

Содержание

Основные сведения

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

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

Процедурные языки программирования

• Ada(язык общего назначения)
• Basic (версии начиная с Quick Basic до появления Visual Basic)
• Си
• КОБОЛ
• Фортран
• Модула-2
• HAL/S
• Pascal
• ПЛ/1
• Рапира
• REXX

См. также

• Функциональное программирование (контраст)
• Логическое программирование
• Императивное программирование
• Парадигмы программирования
• Язык программирования
• Объектно-ориентированное программирование

Литература

• Джозеф Джарратано, Гари Райли Глава 10. Процедурное программирование // «Экспертные системы: принципы разработки и программирование» : Пер. с англ. — М. : 2006. — 779—851 стр., «Вильямс»

Ссылки

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

Wikimedia Foundation . 2010 .

Смотреть что такое «Процедурное программирование» в других словарях:

Программирование — Эта статья должна быть полностью переписана. На странице обсуждения могут быть пояснения. У этого термина существуют и другие значения, см. Программи … Википедия

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

Структурное программирование — Эта статья или раздел нуждается в переработке. Пожалуйста, улучшите статью в соответствии с правилами написания статей … Википедия

Неструктурированное программирование — Структурное программирование методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 70 х годах XX века Э. Дейкстрой, разработана и дополнена Н. Виртом. В … Википедия

Аспектно-ориентированное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия

Императивный язык программирования — Процедурное (императивное) программирование является отражением архитектуры традиционных ЭВМ, которая была предложена фон Нейманом в 40 х годах. Теоретической моделью процедурного программирования служит алгоритмическая система под названием… … Википедия

C++ — У этого термина существуют и другие значения, см. C. См. также: Си (язык программирования) C++ Семантика: мультипарадигмальный: объектно ориентированное, обобщённое, процедурное, метапрограммирование Тип исполнения: компилируемый Появился в … Википедия

ООАП — Объектно ориентированное программирование (ООП) парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием прототипов). Класс это тип, описывающий… … Википедия

Объектно-ориентированный подход — Объектно ориентированное программирование (ООП) парадигма программирования, в которой основными концепциями являются понятия объектов и классов (либо, в менее известном варианте языков с прототипированием прототипов). Класс это тип, описывающий… … Википедия

ДРАКОН (алгоритмический язык) — У этого термина существуют и другие значения, см. Дракон (значения). Пример блок схемы алгоритма на языке ДРАКОН дракон схемы ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность) визуальный… … Википедия

Парадигмы программирования

3.1. Введение. Общие сведения о парадигмах

Общие сведения о парадигмах программирования

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

• 1957г., процедурная парадигма, язык ФОРТРАН, создатель Бэкус;
• 1967г., функциональная парадигма, язык ЛИСП , создатель Маккарти;
• 1970г., структурированная парадигма, язык ПАСКАЛЬ, создатель Вирт;
• 1974г., логическая парадигма, язык ПРОЛОГ;
• 1983г., объектно-ориентированная парадигма, пример — язык C++, создатель Страуструп.

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

В процессе своего развития эти парадигмы «мутировали», «отпочковывались», «объединялись» (так, язык Си объединил в себе процедурную и структурированную парадигму). В результате этих » мутаций » по состоянию на 01.06.2008 года оформились следующие парадигмы программирования :

1. Процедурная (или модульная) парадигма;
2. Логическая парадигма;
3. Объектно-ориентированная парадигма.

Эти три совершенно разные по подходу парадигмы составляют основу современного программирования. Хотя в настоящее время наиболее «модной» является объектно-ориентированная парадигма, остальные парадигмы также используются на практике и изучаются в ВУЗах. Их мы и рассмотрим ниже.

Кроме деления языков программирования по парадигмам, существует также деление языков на » императивные » и «декларативные».

Императивными называются такие языки программирования, в которых описываются в основном «инструкции» по пошаговому выполнению алгоритмов. Все внимание в них отводится лишь реализации этой последовательности действий, а данным и их структуре отводится второстепенная роль. Примером такого рода языков может служить языки создания драйверов устройств: Assembler и C++. При использовании этих языков мы не знаем, какие данные будет отправлять/получать устройство, но зато мы знаем, какие действия нужно осуществить над данными.

Декларативными называются языки программирования, в которых алгоритм работы с данными «зашит» в языке программирования, а сама программа представляет собой данные, упорядоченные и структурированные таким образом, что их легко обрабатывают «стандартные» алгоритмы вывода. В декларативных языках как бы «нет разницы» между данными и алгоритмом, их обрабатывающим. От «значения» данных, подаваемых на вход программы, зависит дальнейшее направление расчетов. Примерами декларативных языков могут служить языки: LISP и Prolog . И программа, и данные на языке ЛИСП представляют собой «списки» вместе с функциями, выполняемыми над ними. На языке ПРОЛОГ есть условное разделение программы на данные («факты») и код («правила», «продукции»). Но это разделение достаточно условно: и факты, и правила имеют одну и ту же форму записи.

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

3.2. Процедурная парадигма

Эта парадигма является самой «древней» и, одновременно, — самой простой в реализации и обучении программирования. На основе этой парадигмы изучаются языки программирования в школе. И поэтому, вполне естественно, автор поставил ее на первое место .

3.2.1. История возникновения парадигмы

«Истоки» процедурной парадигмы программирования лежат в далеких 50-х годах прошлого века. После появления ЭВМ с архитектурой «фон Неймана» появилась возможность компьютеру «самому», без участия человека, проводить сложные вычисления. Эти годы и стали переломными в становлении профессии «программист». Чтобы произвести сложные вычисления, нужно сначала написать сложный алгоритм. Поскольку сложный алгоритм трудно реализовать в ЭВМ так же, как на калькуляторе, появилась необходимость в «записи» алгоритмов на более «понятном» человеку языке, чем язык машинных кодов ЭВМ. Так, вначале появился язык ассемблера, представляющий машинные коды в » удобочитаемом » виде.

В 1957 году Бэкус разработал первый язык высокого уровня: ФОРТРАН. Эта аббревиатура переводится как: » FORmula TRANslator», — переводчик формул. Как следует из его названия, его назначение — это числовые вычисления. С помощью этого языка можно было «кодировать» численные алгоритмы, не вдаваясь в архитектуру ЭВМ, количество регистров в ее процессоре, особенности ее функционирования, и другие, «не важные» для прикладного программиста вопросы. Вскоре, в начале 60-х годов прошлого века, появился язык: » COBOL «, — язык, предназначенный для коммерческих вычислений. Аббревиатура » COBOL » расшифровывается как: «COmmon Business Oriented Language» — «язык, ориентированный на общий бизнес».

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

Таким образом, возникла «процедурная парадигма», гласящая:

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

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

3.2.2. Языки, поддерживающие парадигму

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

• Ассемблер ;
• Фортран;
• Кобол;
• Алгол ;
• PL 1;
• Бейсик;
• Си;
• Паскаль;
• Perl;
• VB Script;
• Jscript ;
• Multi Edit Macro Script;
• MS-DOS Command Shell;
• NDOS Shell;
• Bash shell;
• tc shell;
• REXX ;
• язык SQL-запросов;
• и др.

Все они поддерживают создание «модулей» — функций и подпрограмм, которые разрабатываются и тестируются независимо, и осуществление «вызовов» между ними.

3.2.3. Представление программ и реализация вычислений

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

3.2.3.1. Quick Basic

В языке Quick Basic есть следующие правила оформления программ:

1. Программа на языке Quick Basic находится в файле с расширением «*. bas «;
2. Основная программа начинается с первого ее оператора;
3. Желательно «нумеровать» все строки файла метками — натуральными числами. Нумерацию строк желательно начинать с числа 10 и задать шаг нумерации тоже 10;
4. Заканчиваться вычисления в программе должны оператором: » STOP «;
5. Завершаться описание всех алгоритмических конструкций в программе необходимо оператором: » END «;
6. На каждый оператор выделяется одна строка;
7. Комментарии к строкам алгоритма должны начинаться отдельной строкой, после ключевого слова: » REM «, которые указываются сразу после метки (или вместо метки);
8. Подпрограммы на языке: «Quick Basic», оформляются отдельно, внутри файла;
9. Оформление подпрограмм начинается с ключевого слова: » SUB «, за которым идет имя подпрограммы;
10. Выполнение программы на языке «Quick Basic», открытой в его оболочке («qbasic.exe»), начинается после выбора меню: «Run» -> «Continue», или нажатием клавиши: «F5».

3.2.3.2. C/C++

На языке Си и, частично, С++, существуют следующие правила оформления программ:

1. Программа на языке Си находится в файле с расширением: «*.c», а на языке C++ — с расширением «*. cpp «;
2. Файлы с «заголовочной частью» к основной программе находятся в файлах с расширением «*.h» и «*.hpp»;
3. Основная программа (которая затем будет запускаться по имени файла, например, «myprog.exe»), должна иметь имя и расширение «myprog.c». То есть, в общем случае, имя основного файла проекта — » .c» (для программ на Си) или » . cpp » (для программ на языке С++), где будет соответствовать имени Вашей программы после компиляции;
4. Файл с программой начинается с включения (в заголовочной части) файлов с расширением «*.h» и «*.hpp», с помощью прагма оператора: » include «. При этом имена заголовочных файлов, находящихся в одном каталоге с файлами-описаниями алгоритма, заключаются в кавычки, а имена файлов, пути к которым прописаны в переменной операционной системы: » INCLUDE «, заключаются между знаками: » «, например:
   • #include
   • #include «myprog.h»

main( int argc, char *argv[], char *env[]) , где

• argc — число аргументов у функции. Эта переменная принимает значение 1 в случае отсутствия опций и параметров, 2 в случае присутствия одного параметра и т.п.;
• *argv[] — массив символьных переменных — указателей на опции и аргументы программы, запускаемой из командной строки. При этом элементу «0» соответствует полное путевое имя файла с запускаемой программой. Элементам с номерами: «1» — «argc-1» соответствуют аргументы программы, набранные в командной строке, с соответствующими номерами (по-порядку);
• *env[] — массив символьных переменных — указателей на системное окружение операционной системы, в которой запускается скомпилированная программа.

Подробнее о других аспектах программирования на C/C++ смотри: [31, 51, 92,78]

3.2.3.3. Perl

В языке Perl существуют следующие правила оформления программных модулей:

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

В части II были представлены базовые компоненты языка С++: встроенные типы данных (int и double), типы классов (string и vector) и операции, которые можно совершать над данными. В части III мы увидим, как из этих компонентов строятся функции, служащие для реализации алгоритмов.

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

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

Для облегчения использования функций С++ предлагает множество средств, рассматриваемых нами в части III. Первым из них является перегрузка. Функции, которые выполняют семантически одну и ту же операцию, но работают с разными типами данных и потому имеют несколько отличающиеся реализации, могут иметь общее имя. Например, все функции для печати значений разных типов, таких, как int, string и т.д., называются print(). Поскольку программисту не приходится запоминать много разных имен для одной и той же операции, пользоваться ими становится проще. Компилятор сам подставляет нужное в зависимости от типов фактических аргументов. В главе 9 объясняется, как объявлять и использовать перегруженные функции и как компилятор выбирает подходящую из набора перегруженных.

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

Функции обмениваются информацией с помощью значений, которые они получают при вызове (параметров), и значений, которые они возвращают. Однако этот механизм может оказаться недостаточным при возникновении непредвиденной ситуации в работе программы. Такие ситуации называются исключениями, и, поскольку они требуют немедленной реакции, необходимо иметь возможность послать сообщение вызывающей программе. Язык С++ предлагает механизм обработки исключений, который позволяет функциям общаться между собой в таких условиях. Этот механизм рассматривается в главе 11.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь вам нуж­но:

• либо пере­пи­сы­вать все функ­ции, что­бы научить их пони­мать новые отве­ты про­ве­ряль­щи­ка адре­сов;
• либо пере­де­лать сам про­ве­ряль­щик адре­сов, что­бы он остал­ся сов­ме­сти­мым со ста­ры­ми места­ми, но в нуж­ном вам месте как-то ещё выда­вал коды оши­бок;
• либо напи­сать новый про­ве­ряль­щик, кото­рый выда­ёт коды оши­бок, а в ста­рых местах исполь­зо­вать ста­рый про­ве­ряль­щик.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Визу­аль­но код ста­но­вит­ся про­ще, и его лег­че читать. Когда всё раз­би­то на объ­ек­ты и у них есть понят­ный набор пра­вил, мож­но сра­зу понять, за что отве­ча­ет каж­дый объ­ект и из чего он состо­ит.
• Мень­ше оди­на­ко­во­го кода. Если в обыч­ном про­грам­ми­ро­ва­нии одна функ­ция счи­та­ет повто­ря­ю­щи­е­ся сим­во­лы в одно­мер­ном мас­си­ве, а дру­гая — в дву­мер­ном, то у них боль­шая часть кода будет оди­на­ко­вой. В ООП это реша­ет­ся насле­до­ва­ни­ем.
• Слож­ные про­грам­мы пишут­ся про­ще. Каж­дую боль­шую про­грам­му мож­но раз­ло­жить на несколь­ко бло­ков, сде­лать им мини­маль­ное напол­не­ние, а потом раз за разом подроб­но напол­нить каж­дый блок.
• Уве­ли­чи­ва­ет­ся ско­рость напи­са­ния. На стар­те мож­но быст­ро создать нуж­ные ком­по­нен­ты внут­ри про­грам­мы, что­бы полу­чить мини­маль­но рабо­та­ю­щий про­то­тип.

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

• Слож­но понять и начать рабо­тать. Под­ход ООП намно­го слож­нее обыч­но­го функ­ци­о­наль­но­го про­грам­ми­ро­ва­ния — нуж­но знать мно­го тео­рии, преж­де чем будет напи­са­на хоть одна строч­ка кода.
• Тре­бу­ет боль­ше памя­ти. Объ­ек­ты в ООП состо­ят из дан­ных, интер­фей­сов, мето­дов и мно­го дру­го­го, а это зани­ма­ет намно­го боль­ше памя­ти, чем про­стая пере­мен­ная.
• Ино­гда про­из­во­ди­тель­ность кода будет ниже. Из-за осо­бен­но­стей под­хо­да часть вещей может быть реа­ли­зо­ва­на слож­нее, чем мог­ла бы быть. Поэто­му быва­ет такое, что ООП-программа рабо­та­ет мед­лен­нее, чем функ­ци­о­наль­ная (хотя с совре­мен­ны­ми мощ­но­стя­ми про­цес­со­ров это мало кого вол­ну­ет).

Что дальше

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

Почему мы должны изучать процедурное программирование, прежде чем изучать объектно-ориентированное программирование [закрыто]

Сейчас я учусь на 4-м курсе в ИТ-университете, и когда я говорю с моим профессором на эту тему, он отвергает мое мнение и дает мне очень жесткую критику (в моем университете нас учили C (ANSI) (в классе процедурного программирования — в 1-м курсе в университете) до C ++ (в классе ООП в 2-м курсе) и другие .

Но в 13 лет я научил моего брата Java прежде всего. Теперь он может делать практически все, что может делать обычный студент 2-го курса с Java.

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

12 ответов

Краткое описание.

Потому что в реальном мире рано или поздно вам придется работать с процедурным кодом.

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

Дополнение к ответу 2. Потому что О.П. это сложнее, чем процедурное программирование, поэтому лучше сначала изучить процедурное программирование.

Поскольку в реальном мире программисты работают и объединяют несколько способов решения проблем, А.К.А. «мультипарадигмальное программирование», а не просто парадигма.

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

[NEW] Поскольку модульное программирование, которое обычно смешивается и путается с процедурным программированием, может применяться к O.O.P. Поэтому вопрос можно прочитать как «Почему мы должны изучать модульное программирование, прежде чем мы изучим объектно-ориентированное программирование»

Расширенное описание скучно:

Точка 1 очень ясна, дальнейших объяснений нет.

Точка 2, Классы, Наследование, Полиморфизм, Интерфейсы и т. д .

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

Я слышал то же самое от людей, которые перешли от простого C к C плюс плюс.

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

Даже Java «Pure O.O.» не такое простое объектное программирование, как говорится.

+1 балл за «процедурное программирование» вместо «структурное программирование». Или Модульное Программирование. Это важно.

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

Сегодня я прочитал несколько «чистых» О.О. программы, которые выглядят как «объектно-ориентированный код спагетти», это означает, что программист использовал O.O.P., но его код выглядит как беспорядок.

Много раз я могу читать О.О. код и скажите, что программист изучил структурированное программирование до O.O.P., потому что код понятен и упорядочен.

А для модульного программирования я видел несколько приложений. в C ++ и PHP, которые не используют модули. *

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

FWIW, он обязательно изменится в конце концов. Когда я пошел в школу, мы учились на Паскале и PL / 1. Мы не добрались до C, пока урок продвинутого языка (который встречается со мной). Я не изучал Java до аспирантуры — она еще не была изобретена!

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

Вы не делаете.

Сначала мы изучили функциональное программирование с помощью Scheme. Затем мы перешли к процедурному, затем ООП и затем декларативному программированию. И верьте, хотите нет, хотя я уже знал программирование, я думаю, что на самом деле это было проще и для других людей: потому что FP — это точно так же, как математика! Так что вы уже знаете основы.

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

Единого ответа нет, потому что:

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

Начинать с чего-то объектно-ориентированного Java может быть хорошим выбором, потому что его относительно легко изучить и применить ООП в реальной жизни, а также потому, что он учит вас ** формированию

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

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

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

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

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

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

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

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

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

Сущность объектов ООП состоит из процедурного программирования.

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

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

ООП не о каком-то объявлении синтаксиса для формирования классов, а о структурах данных, шаблонах проектирования, полиморфизме, наследовании и композиции.

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

На вашем месте я бы взял некоторые из следующих книг: Язык программирования C , Язык программирования Java , Шаблоны проектирования , Банда четырех и Выкройка шаблонов . Я бы определенно взял копию языка программирования C , если бы я серьезно относился к C / C ++.

Если вы просто хотите пройти весь путь до Java (и делаете это за $), найдите несколько книг по шаблонам проектирования Java и о том, как использовать Java с веб-серверами Apache и Tomcat, и несколько книг по программированию баз данных SQL. Java так много задевает в Интернете, извините, но у PHP была история с множеством дыр в безопасности, из-за которой Windows и задница доставляли такую же боль, как и Windows, чтобы не получить рутования вашего сервера или внедрения баз данных SQL.

Вы также должны уделить время изучению SQL, Oracle MySQL Postgresql и MSSQL имеют много общего в отношении синтаксиса, но если мне нужно было просто выбрать изучение одного для себя, то я выберу Postgresql только потому, что он лицензирован по BSD вместо GPL (вы должны посмотреть сравните и сопоставьте лицензии GPL / BSD тоже)