4 О парадигмах

      Комментарии к записи 4 О парадигмах отключены

Помечено: ,

В этой теме 0 ответов, 1 участник, последнее обновление  Васильев Владимир Сергеевич 4 мес., 2 нед. назад.

  • Автор
    Сообщения
  • #3575

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

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

    Самая частая ошибка — это совместное использование грамматики C++ и библиотечных функций языка C. Конкретных примеров можно привести сколько угодно: это и совместное использование потоков ввода-вывода с библиотекой <stdio.h>, и использование C-style cast для приведения полиморфных типов, и подготовка текста исключения с помощью функций в printf-стиле, и завершение программы с помощью функции exit, и так далее. Этот список можно продолжать еще очень долго.

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

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

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

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

    Если отвлечься от языка C++, то попробуйте взглянуть на реализацию оконного приложения, использующего WinAPI, на каком-нибудь функциональном языке, как вариант — на Прологе или на Erlang — и вы увидите, на сколько уродливо выглядит использование процедурного API в функциональном языке.

    Резюме

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

Для ответа в этой теме необходимо авторизоваться.