Брутально и бессердечно о программировании и проектировании
ГлавнаяФорумПаттерныАнтипаттерныТест-драйвЗаметкиВопрос-ответКнигорецензииСправочная

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

Чтобы научиться правильно пользоваться инструментом, необходимо понимать, для чего он предназначен. Каждая парадигма программирования представляет собой инструмент, предназначенный для решения определенного круга задач. Самый верный способ наделать ошибок — использовать инструмент не по назначению.
Я видел довольно много примеров такого вот неправильного использования в крупных коммерческих проектах, не говоря уже о коде любителей-энтузиастов или университетских преподавателей.
Самая частая ошибка — это совместное использование грамматики C++ и библиотечных функций языка C. Конкретных примеров можно привести сколько угодно: это и совместное использование потоков ввода-вывода с библиотекой <stdio.h>, и использование C-style cast для приведения полиморфных типов, и подготовка текста исключения с помощью функций в printf-стиле, и завершение программы с помощью функции exit, и так далее. Этот список можно продолжать еще очень долго.
Дело в том, что когда господа Ритчи и Керниган изобретали язык C, они понятия не имели о том, что он через некоторое время эволюционирует в язык C++, который, в свою очередь, унаследует его грамматику и библиотеки, поэтому у них просто не было возможности сделать его совместимым с языком C++. Это, конечно, камень в огород Страуструпа — базовую грамматику языка можно было бы и пересмотреть, а стандартные библиотеки языка C — вообще выкинуть.
Однажды я видел практически полноценный динамический полиморфизм объектов, реализованный на плоском C. Это, естественно, было безжалостно и беспощадно. Несколько десятков страниц макросов, enum-ов и функций. Однако, это был реальный коммерческий продукт, который мне по долгу службы приходилось использовать.
Другой пример — коммерческий продукт, в разработке которого мне не посчастливилось принимать участие, в котором помимо всех прочих бесчисленных ошибок, жестко сочетались процедурный подход с исключениями в качестве механизма обработки ошибок. При этом такие элементарные понятия, как безопасность с точки зрения исключнией, конечно же, никого не волновали. Практически любое исключение в программе приводило к утечке ресурсов. Тем не менее, продукт продавался.
Но самое брутальное и бессердечное из того, что мне приходилось видеть в коммерческих продуктах, было полноценным динамическим полиморфизмом, реализованном на макросах и механизме исключений. Так уж получилось, что автор проекта знал обо всех возможностях языка C++, кроме виртуальных функций. вместо вызова виртуальной функции кидалось специальное исключение, а последовательность блоков catch выступала в роли динамического диспетчеризатора. Вот это было реально круто — если бы был конкурс работ на самую нестандартную реализацию какого-нибудь стандартного механизма, то я бы отдал этой работе первое место, хоть она и абсолютно несовместима с реальной жизнью.
Если отвлечься от языка C++, то попробуйте взглянуть на реализацию оконного приложения, использующего WinAPI, на каком-нибудь функциональном языке, как вариант — на Прологе или на Erlang — и вы увидете, на сколько уродливо выглядит использование процедурного API в функциональном языке.
 
Резюме
Если вы решили воспользоваться какой-то парадигмой программирования в решении какой-то конкретной задачи, то используйте только наиболее естественные для этой парадигмы инструменты. Не нужно изобретать велосипед на воздушной подушке — набор инструментов для каждой парадигмы уже давно устоялся, обкатался, и проверился временем. Вопрос лишь в том, как вы будете использовать эти инструменты.

Оглавление
Статистика
© 2007—2009 Inside C++ Коммерческие услугиКонтактная информация

Рекомендуем: арбалет чёрный питон. лук ястреб arbaletchik.ru. скачать skype, софт, кодеки скачать. квартиры краснодара. стальные двери профмастер стальные двери дом