Секция «Проблемы преподавания информатики. Парадигмы и технологии программирования Парадигмы программирования

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

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

Единственно прошу, если прочитали по диагонали - комментируйте сдержано.

Что нам говорит Флойд о парадигмах?

Термин «парадигма программирования» ввел Роберт Флойд (""R. W. Floyd."" ""Communications of the ACM"", 22(8):455-460, 1979. Русский перевод см. в кн.: Лекции лауреатов премии Тьюринга за первые двадцать лет (1966-1985), М.: МИР, 1993.). Он в своей лекции в 1979 году говорит о следующем:

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

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

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

Особенности парадигм более высокого уровня

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

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

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

Основы парадигмы структурного программирования

Мы знаем, что идеи о структурном программировании возникли после доклада Э. Дейкстры еще в 1965 году, где он обосновал отказ от оператора GOTO. Именно этот оператор превращал программы в неструктурированные (Спагетти-код), а Дейкстра доказал, что возможно написать программы без использования этого оператора в результате чего программы станут структурными.

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

Но что было тогда? Как описывает Йодан, все начинается с ответа на вопрос: «Что значит написать хорошую программу?». Вот первый критерий, на какие вопросы должна отвечать парадигма программирования высокого уровня. Если она не отвечает прямо на этот вопрос, а рассказывает вам как можно получить некоторые интересные характеристики вашей программы, то вы имеете дело с парадигмой низкого уровня - подходом при программировании.

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

Примечателен, довольно характерный спор программистов:
* Программист А: “Моя программа в десять раз быстрее вашей, и она занимает в три раза меньше памяти!”
* Программист Б: “Да, но ваша программа не работает, а моя - работает!”

Но программы постоянно усложняются и поэтому нам недостаточно того, что программа просто работает. Нужны определенные методы верификации правильности работы программы и самого программиста. Причем это не тестирование программы, а проведение некоторой систематической процедуры проверки именно правильности программы в смысле её внутренней организации. То есть уже тогда, говоря современным языком, говорили о ревизии кода (Code review).

Кроме того, уже тогда говорили о гибкости программы - о простоте ее изменения, расширения и модификации. Для этого необходимо постоянно отвечать на вопросы определенного вида. “Что будет, если мы захотим расширить эту таблицу?”, “Что произойдет, если однажды мы захотим определить новую программу изменений?”, “А что, если нам придется изменить формат таких-то выходных данных?”, “Что будет, если кто-то решит вводить данные в программу другим способом?”.

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

Кроме того, центральное внимание уделяли размеру и неизменности модуля. Причем что касается неизменности модуля, то она рассматривалась не целиком, а с выделением отдельных факторов:
1. Логическая структура программы, т.е. алгоритм. Если вся программа зависит от некоторого специального подхода, то в скольких модулях потребуется внести изменения при изменении алгоритма?
2. Аргументы, или параметры, модуля. Т.е. изменение спецификации интерфейсов.
3. Внутренние переменные таблиц и константы. Многие модули зависят от общих таблиц, если изменяется структура таких таблиц, то мы можем ожидать, что модули также изменятся.
4. Структура и формат базы данных. В большей степени эта зависимость аналогична зависимости от общих переменных и таблиц, упомянутой выше, с той разницей, что с практической точки зрения базу данных удобнее считать независимой от программы.
5. Модульная структура управления программой. Некоторые пишут модуль не особенно задумываясь над тем, каким образом он будет использоваться. Но если изменились требования. Какую часть логической структуры модуля нам придется изменить?

Эти и множество других аспектов (которые мы тут не рассмотрели) в целом и формулируют представление о структурном программировании. Забота об этих аспектах и делает структурное программирование парадигмой высокого уровня.

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

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

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

Уже признано, что причиной появления объектно-ориентированной парадигмы стала необходимость писать все более и более сложные программы, в то время как парадигма структурного программирования имеет некий предел, после которого развивать программу становится невыносимо сложно. Вот, например, что пишет Г. Шилдт:

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

Чтобы понять причину, почему именно объектно-ориентированное программирование, позволило писать более сложные программы и практически убрать проблему возникновения предела сложности, обратимся к одному из основоположников ООП - Гради Бучу (). Свое объяснение ООП он начинает с того, что значит сложность и какие системы можно считать сложными. То есть целенаправленно подходит к вопросу написания сложных программ. Далее переходит к вопросу связи сложности и человеческих возможностей понять эту сложность:

Существует еще одна главная проблема: физическая ограниченность возможностей человека при работе со сложными системами. Когда мы начинаем анализировать сложную программную систему, в ней обнаруживается много составных частей, которые взаимодействуют друг с другом различными способами, причем ни сами части системы, ни способы их взаимодействия не обнаруживают никакого сходства. Это пример неорганизованной сложности. Когда мы начинаем организовывать систему в процессе ее проектирования, необходимо думать сразу о многом. К сожалению, один человек не может следить за всем этим одновременно. Эксперименты психологов, например Миллера, показывают, что максимальное количество структурных единиц информации, за которыми человеческий мозг может одновременно следить, приблизительно равно семи плюс-минус два. Таким образом, мы оказались перед серьезной дилеммой. """Сложность программных систем возрастает, но способность нашего мозга справиться с этой сложностью ограничена. Как же нам выйти из создававшегося затруднительного положения?"""

Затем он говорит о декомпозиции:

Декомпозиция: алгоритмическая или объектно-ориентированная? Какая декомпозиция сложной системы правильнее - по алгоритмам или по объектам? В этом вопросе есть подвох, и правильный ответ на него: важны оба аспекта. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия. Однако мы не можем сконструировать сложную систему одновременно двумя способами. Мы должны начать разделение системы либо по алгоритмам, либо по объектам, а затем, используя полученную структуру, попытаться рассмотреть проблему с другой точки зрения. Опыт показывает, что полезнее начинать с объектной декомпозиции. Такое начало поможет нам лучше справиться с приданием организованности сложности программных систем.

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

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

Теперь, если посмотреть внимательнее, оказывается, что объектно-ориентированная парадигма есть не что иное как моделирование вообще, наиглавнейший аспект которого наиболее четко выразил С. Лем:

Моделирование - это подражание Природе, учитывающее немногие ее свойства. Почему только немногие? Из-за нашего неумения? Нет. Прежде всего потому, что мы должны защититься от избытка информации. Такой избыток, правда, может означать и ее недоступность. Художник пишет картины, но, хотя мы могли бы с ним поговорить, мы не узнаем, как он создает свои произведения. О том, что происходит в его мозгу, когда он пишет картину, ему самому неизвестно. Информация об этом находится в его голове, но нам она недоступна. Моделируя, следует упрощать: машина, которая может написать весьма скромную картину, рассказала бы нам о материальных, то есть мозговых, основах живописи больше, чем такая совершенная «модель» художника, какой является его брат-близнец. Практика моделирования предполагает учет некоторых переменных и отказ от других. Модель и оригинал были бы тождественны, если бы процессы, происходящие в них, совпадали. Этого не происходит. Результаты развития модели отличаются от действительного развития. На это различие могут влиять три фактора: упрощенность модели по сравнению с оригиналом, свойства модели, чуждые оригиналу, и, наконец, неопределенность самого оригинала. (фрагмент произведения «Сумма технологий», Станислав Лем, 1967)

Таким образом, С. Лем говорит о абстрагировании как основе моделирования. В тоже время абстрагирование и есть главный признак объектно-ориентированной парадигмы. Г. Буч по этому поводу пишет:

Разумная классификация, несомненно, - часть любой науки. Михальски и Степп утверждают: «неотъемлемой задачей науки является построение содержательной классификации наблюдаемых объектов или ситуаций. Такая классификация существенно облегчает понимание основной проблемы и дальнейшее развитие научной теории». Почему же классификация так сложна? Мы объясняем это отсутствием «совершенной» классификации, хотя, естественно, одни классификации лучше других. Кумбс, Раффья и Трал утверждают, что «существует столько способов деления мира на объектные системы, сколько ученых принимается за эту задачу». Любая классификация зависит от точки зрения субъекта. Флуд и Кэрсон приводят пример: «Соединенное Королевство… экономисты могут рассматривать как экономический институт, социологи - как общество, защитники окружающей среды - как гибнущий уголок природы, американские туристы - как достопримечательность, советские руководители - как военную угрозу, наконец, наиболее романтичные из нас, британцев - как зеленые луга родины».

"""Поиск и выбор ключевых абстракций.""" Ключевая абстракция - это класс или объект, который входит в словарь проблемной области. """Самая главная ценность ключевых абстракций заключена в том, что они определяют границы нашей проблемы""": выделяют то, что входит в нашу систему и поэтому важно для нас, и устраняют лишнее. Задача выделения таких абстракций специфична для проблемной области. Как утверждает Голдберг, «правильный выбор объектов зависит от назначения приложения и степени детальности обрабатываемой информации».
Как мы уже отмечали, определение ключевых абстракций включает в себя два процесса: открытие и изобретение. Мы открываем абстракции, слушая специалистов по предметной области: если эксперт про нее говорит, то эта абстракция обычно действительно важна. Изобретая, мы создаем новые классы и объекты, не обязательно являющиеся частью предметной области, но полезные при проектировании или реализации системы. Например, пользователь банкомата говорит «счет, снять, положить»; эти термины - часть словаря предметной области. Разработчик системы использует их, но добавляет свои, такие, как база данных, диспетчер экрана, список, очередь и так далее. Эти ключевые абстракции созданы уже не предметной областью, а проектированием.
Наиболее мощный способ выделения ключевых абстракций - сводить задачу к уже известным классам и объектам.

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

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

Да, и еще, чтобы было понятно - опубликовать я решил после дискуссий здесь Запрограммируем перцептрон Розенблатта? , где очевидным образом стало понятно, что функциональное программирование при построении плохой модели в ООП работает хуже не куда. И то, что они хвалятся супер скоростью - это фикция, на самом деле важна правильная модель. Для некоторых (не много таких задач сравнительно) функциональное программирование может быть успешным, но его не нужно использовать повсеместно, там где оно не дает ничего хорошего. Ну, или так - сможете написать обсуждаемый там кусок ТОЛЬКО в функциональном стиле, и чтобы это работало быстрее, чем с событиями ООП?

Теги: Добавить метки

Парадигма программирования - это совокупность идей и понятий, определяющая стиль написания программ.

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

Первыми императивными языками были машинные коды - родной язык программирования для компьютера. В этих языках инструкции были крайне просты, что снижало нагрузку на компьютеры, однако затрудняло написание крупных программ. В 1954 появился первый «человеческий» язык программирования - FORTRAN, затем ALGOL, COBOL, BASIC, Pascal, C.

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

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

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

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

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

· императивная парадигма наиболее близка природе компьютера, основным принципам его функционирования, так как, не смотря на всю сложность современного компьютера, на уровне аппаратной части его можно по-прежнему рассматривать как некоторый автомат (процессор+память+…) с конечным множеством состояний (содержимого памяти);

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

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

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

Недостаток: в чистом виде позволяет решать только очень простые задачи.

Событийно-управляемое программирование - программирование, при котором задаются реакции программы на различные события (действия пользователя). СУП можно рассматривать как «потомок» императивной парадигмы. СУП имеет 2 подкласса:

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

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

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

Важно выделить следующие основные свойства объектов:

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

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

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

Многие современные языки поддерживают ООП, хотя и в разной степени: - чисто объектно-ориентированные языки, например, Smalltalk и Ruby, разработаны для того, чтобы поддерживать и даже навязывать объектно-ориентированный стиль разработки, и не поддерживают другие стили программирования; - преимущественно объектно-ориентированные языки, например, Java, C++ и Python, разработаны в основном для поддержки ООП, но позволяют использовать элементы процедурного программирования; - исторически процедурные языки, например, Perl и Fortran 2002, были доработаны и в них была добавлена поддержка некоторых элементов ООП.

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

Декларативное программирование является противоположностью императивного программирования; первое описывает, что необходимо сделать, а второе - как именно это сделать.

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

1.Функциональное программирование представляет собой одну из альтернатив императивному подходу. Оно основано на лямбда-исчислении Черча. В императивном программировании алгоритмы - это описания последовательно исполняемых операций. Здесь существует понятие "текущего шага исполнения" (то есть, времени), и "текущего состояния", которое меняется с течением этого времени.

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

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

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

Логическое программирование

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

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

Логическое программирование допускает естественную параллельную реализацию.

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

Определение парадигмы звучит обычно таким образом:

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

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

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

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

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

Перечислим самые популярные из них:

Императивное программирование
Структурное программирование
Декларативное программирование
Объектно-ориентированное программирование

На самом деле, есть ещё множество других парадигм, которые мы не перечислили в списке, мы охватываем лишь самые известные из них.

Кратко рассмотрим каждую из них

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

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

от английского imperative - приказ

отличительные черты императивного программирования:

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

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

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

Языки представители парадигмы: машинные (бинарные) коды, Ассамблер, fortran, algol, cobol

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

предложил этот метод нидерландский ученый

Эдсгер Дейкстра 1930 — 2002г

А вот основным в структурном программировании является понятие блоков и иерархической структуры и в которой используются три основных управляющих структур:

последовательность
ветвление

Структурное программирование имеет также 7 принципов, описанный Дейкстрой:

полный отказ использования оператора goto; *
любая программа строиться на трех управляющих структурах последовальность, цикл и ветвление;
базовые управляющие структуры могут быть вложены в друг друга, как угодно;
Повторяющие компоненты, оформлять как подпрограммы;
каждая логическая структура следует оформлять как блок;
все структуры должны имеет один вход и один выход, и не более;
разработка программы должна идти пошагово «лестницей» (методом сверху вниз)

* —
goto — оператор безусловного перехода, который широко использовался в 1970-х

Декларативное программирование

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

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

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

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

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

Абстракция данных — выделение значимой информации и отделение её от незначимой.

Инкапсуляция — это такое свойство которое позволяет объединить данные, методы в классе

Наследование — свойство которое позволяет создать новый класс на основе старого (унаследовать все его свойства)

Полиморфизм — а это свойство позволяет использовать объекты с одинаковым интерфейсом

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

Рис. 2.6. Эволюция парадигм программирования.

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

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

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

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

Функциональная парадигма рассматривает процесс разработки программы как соединение «черных ящиков», каждый из которых получает входные данные и порождает выходные данные так, чтобы создать необходимую зависимость между ними. Математики называют эти «ящики» функциями, именно поэтому подход и называется функциональным. Примитивы функционального языка программирования являются элементарными функциями, из которых можно построить более сложные функции, необходимые для решения некоторой задачи. Таким образом, программист, придерживающийся функциональной парадигмы, создает программное обеспечение, объединяя элементарные функции в систему, которая порождает необходимый результат. Проще говоря, процесс программирования сводится к построению сложных функций из более простых (например, в Паскале sin(sqr(x))).

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

Ниже приведены примеры запись команд на LISP, который относится к функциональным языкам:

1) (MAX_число1_число2_ ... числоN) - максимальное из чисел;

2) (+_число1_число2_ ... числоN) – сложение;

3) (SETQ_символ1_S-exp1_ .... символN_S-expN) - связывает имя со значением выражения.;

4) (EVAL_(/_(-_(*_ 2_7)_5)_2)) - вычисление значения выражения (2*7-5)/2;

5) (SETQ_f_1) (WHILE_(<_f_10)_(SETQ_f_(+_f_3))) – присваиваем переменной f значение 1 и увеличиваем переменную f на три, до тех пор, пока f меньше 10.

Объектно-ориентированная парадигма и соответствующее ей объектно-ориентированное программирование (ООП) представляют собой еще один подход к процессу разработки программного обеспечения. Данные при этом подходе рассматриваются как активные «объекты», а не как пассивные единицы, представленные в обычной императивной парадигме. Например, рассмотрим список имен. В императивной парадигме этот список рассматривается просто как набор данных. Любая программа, пытающаяся получить доступ к списку, должна содержать алгоритм, выполняющий необходимые действия (чтение списка и т.п.). Таким образом, список обслуживается управляющей программой. При объектно-ориентированном подходе список рассматривается как объект, состоящий из самого списка и процедур для манипуляции им. Это могут быть программы для помещения в список нового элемента, удаления элемента из списка, проверки наличия элемента в списке и сортировки списка. В свою очередь, программе, пытающейся получить доступ к списку, совсем не обязательно содержать алгоритмы для выполнения этих задач. Вместо этого она использует процедуры объекта. Можно сказать, что программа просит список отсортировать себя, а не сама сортирует его.

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

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

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

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

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

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

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

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

Прикладное программирование подчинено проблемной направленности, отражающей компьютеризацию информационных и вычислительных процессов численной обработки, исследованных задолго до появления ЭВМ. Именно здесь быстро проявился явный практический результат. Естественно, в таких областях программирование мало чем отличается от кодирования, для него, как правило, достаточно операторного стиля представления действий. В практике прикладного программирования принято доверять проверенным шаблонам и библиотекам процедур, избегать рискованных экспериментов. Ценится точность и устойчивость научных расчетов. Язык Фортран -- ветеран прикладного программирования, постепенно стал несколько уступать в этой области Паскалю, Си, а на суперкомпьютерах -- языкам параллельного программирования, таким как Sisal.

Теоретическое программирование придерживается публикационной направленности, нацеленной на сопоставимость результатов научных экспериментов в области программирования и информатики. Программирование пытается выразить свои формальные модели, показать их значимость и фундаментальность. Эти модели унаследовали основные черты родственных математических понятий и утвердились как алгоритмический подход в информатике. Стремление к доказательности построений и оценка их эффективности, правдоподобия, правильности, корректности и других формализуемых отношений на схемах и текстах программ послужили основой структурированного программирования и других методик достижения надежности процесса разработки программ, например грамотное программирование. Стандартные подмножества Алгола и Паскаля, послужившие рабочим материалом для теории программирования, сменились более удобными для экспериментирования аппликативными языками, такими как ML, Miranda, Scheme, Haskell и другие. Теперь к ним присоединяются нововведения в C и Java.

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

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

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

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

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

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

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

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

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

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

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