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

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

ООП внесло много ограничений по сравнению со структурным программированием:

–в ООП алгоритмы привязаны к данным, запрещена косвенная передача управления;

–ООП требует избегать избыточного описания предметной об-

ласти;

–ООП требует наследовать характеристики объектов вместо их копирования;

–ООП предполагает жёсткое разделение алгоритмов по облас-

тям видимости.

Ксовременным объектно-ориентированным языкам в первую оче-

редь можно отнести такие языки, как Java и C#. Языки C++ и Delphi яв-

ляются объектно-ориентированными, но они появились на основе язы-

ков структурного программирования C и Pascal, что не позволяет их на-

звать полностью объектно-ориентированными (часть функций в них выполняется без контекста). Язык Python объектно-ориентированным можно назвать лишь условно: он позволяет легко писать в структурно-

ориентированном стиле и не имеет некоторых современных аспектов,

относящихся к ООП.

2.4. Функциональное программирование

Существенным недостатком ООП является лёгкий доступ к кон-

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

24

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

деть не связанный с «Питаться» параметр. Подобные ситуации называ-

ются побочными эффектами [25, 28, 29], и их, очевидно, необходимо избегать, так как их исправление в сложных системах занимает очень много времени. Не всегда можно быстро заметить связь между кормле-

нием «Собаки» и увеличением её хвоста. Скорее всего, на исправление разработчику поступит задача: «у некоторых собак хвост растёт бы-

стрее, чем обычно». Найти и исправить такую ошибку среди сотен ты-

сяч строк кода – очень сложная и зачастую не решаемая задача.

Парадигма функционального программирования оперирует поня-

тием «чистой функции», т.е. такой функции, у которой нет побочных эффектов [25]. Такая функция полностью описывается своей сигнату-

рой (т.е. именем, набором входных параметров и набором возвращае-

мых значений).

Помимо понятия чистой функции в основе парадигмы также ле-

жат:

–функции высших порядков (функции, принимающие и возвра-

щающие в качестве операторов другие функции);

–каррирование (преобразование функции от нескольких пере-

менных к функции, берущей свои переменные по одному);

–использование рекурсии как основного способа организации циклов;

–обработка коллекций по принципу «голова | хвост» (в коллек-

ции явно выделяются первый её элемент и все последующие,

что позволяет использовать каррированные и рекурсивные

функции для обработки данных).

25

Первым функциональным языком можно считать язык программи-

рования LISP, появившийся в 1958 году [30]. Несмотря на то, что функ-

циональное программирование появилось раньше всех рассмотренных выше парадигм, популярность его стала расти лишь относительно не-

давно в силу высокого порога входа. При этом чистые функционально-

ориентированные языки программирования не получили широкого рас-

пространения: вместо этого отдельные концепции парадигмы включа-

ются в объектно-ориентированные языки.

2.5. Общие тенденции развития парадигм программирования

Стоит обратить внимание, что все рассмотренные выше парадигмы программирования появились примерно в одно и то же время (пример-

но в течение 1960-х годов). При этом с начала 1980-х годов (т.е. более чем за 40 лет) не появилось больше ни одной новой парадигмы.

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

можно сделать вывод, что чем более сложные информационные систе-

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

(или их комбинация) применяются в такой разработке [25]. Такая тен-

денция может быть объяснена тем, что разработчикам ИС приходится в первую очередь «бороться» со сложностью автоматизируемых ими предметных областей и лишь во вторую очередь фокусироваться на на-

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

позволяет «выжать максимум» из такой реализации. Однако при разра-

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

«перетягивать» на себя внимание разработчиков.

26