[ <<< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Источники | >>> ]
© 2001 А.И. Легалов
После столь длительного лирического вступления, мне бы хотелось отметить специфику собственных интересов. Меня интересует техника эволюционной разработки программ и ее зависимость от избранной парадигмы программирования. Дело в том, что разрабатывать такие программы можно и без использования объектно-ориентированного подхода, что может нести свои плюсы и минусы. ООП, в данной сфере, тоже обладает не только достоинствами, но и (на мой взгляд) недостатками. Скорее всего, эволюционное программирование тоже должно быть двуруким. Однако для этого необходимо более четко определить: чем отличаются друг от друга ПП и ООП. Поиском ответа на поставленный вопрос я и пытаюсь заняться в представленных заметках. Несмотря на попытку объективного анализа, я, все-таки, высказываю свою, чисто субъективную точку зрения, которая, по некоторым аспектам, вполне может оказаться ошибочной. Поэтому, с благодарностью приму любые конструктивные замечания и предложения, обеспечивающие согласованное общее восприятие "Мира программирования". В этот раз я никого не собираюсь провоцировать (зачем дважды подставлять одни и те же грабли:), а просто выношу на всеобщее обозрение ряд актуальных, на мой взгляд, вопросов. Сразу хочу сказать, что этот материал является далеко не последним в общей серии, посвященной парадигмам программирования.
В представленных заметках я попытался отделить методы кодирования, определяемые различными парадигмами, от методологических аспектов, особенностей реализации и функционального наполнения. Такое обособление позволяет, на мой взгляд, провести более четкую границу между техникой, используемой при формировании кода, и концептуальными умозаключениями, построенными на основе комплексного восприятия решаемой задачи, реального мира, мира моделей и аппаратных ресурсов.
Я давно перешел в разряд отцов, и, по определению Тургенева, устарел. Проявлением консерватизма является и использование мною определений терминов, построенных еще в незапамятные времена [АРНФС]. В настоящее время многие из них слегка изменили окраску. Поэтому под программированием я понимаю, то, что ныне воспринимается как кодирование. Сейчас, довольно часто, программирование ассоциируется с элементами проектирования.
Более широкую трактовку приобрел термин "парадигма программирования". Он иногда воспринимается не только как стиль программирования, навязанный языком (техника кодирования), но метод, определяющий технику разработки программ в конкретной предметной области. Не вдаваясь в дискуссию по поводу терминологических метаморфоз, буду в дальнейшем считать близкими по смыслу понятия: программирование и кодирование, парадигма программирования и техника кодирования.
Стоит отметить и термин "эволюционное программирование". Он прямо не связан с эволюционной разработкой и спиральной моделью. Косвенная связь заключается в следующем. Закончив очередной виток эволюционного цикла разработки версии продукта, мы получаем на выходе код, написанный на некотором языке программирования. Новый виток спирали требует расширения и модификации этого кода, то есть его эволюции. Он не создан волшебником, его невозможно автоматически сгенерировать при повторном проектировании. При этом желательно как можно меньше изменять уже написанный код, используя методы, позволяющие его наращивать. То есть (учитывая метаморфозы терминологии), эволюционное программирование можно ассоциировать с эволюционным кодированием. В целом же эта задача была поставлена до меня. Поэтому не буду останавливаться на ее особенностях. Ниже рассмотрена возможность использования различной техники кодирования для эволюционного расширения уже написанной программы.
Использование этих терминов, в какой-то мере объясняет стремление очиститься и от ряда наслоений на программирование (кодирование).
Нельзя отрицать ту важную роль, которую играют методологии в процессе разработки программного обеспечения. Но они больше связаны с философским восприятием и отображением окружающего нас мира, чем с техникой кодирования. Для методологий важнее то, в какой последовательности они используют различные модели, а не то, в какой код они при этом отображаются. Фиксация последовательности шагов ведет к однобокому восприятию окружающего нас мира (что вполне соответствует и различным философским учениям). Например, независимо от того, обладает реальный объект поведением или нет, ОО подход навязывает ему внутренние методы. И хотя, на конечной реализации такое навязывание может и не сказываться, я не считаю правильным использовать одинаковые модели для театра людей и театра марионеток. Вряд ли здесь стоит говорить об одинаково адекватном отражении в общей объектной модели реалий окружающих нас миров. Полагаю, что по этому вопросу могут возникнуть альтернативные суждения. Поэтому сразу отказываюсь от дальнейших бесплодных (философских:) дискуссий.
Методологии могут одинаково манипулировать ортогональными понятиями рассматриваемой предметной области. Используя одни и те же методы, в той ж самой последовательности, но в "нестандартном" контексте можно получать аналогичные результаты. Об этом, в несколько утрированной форме я и пытался сказать в заметках, посвященных процессо-ориентированному программированию.
Именно из этих соображений я попытался отсечь методологический аспект, чтобы более конкретно рассмотреть реальную технику создания кода, поддерживаемую на уровне языков.
Точно таким же образом я попытался абстрагироваться и от отображения языковых конструкций на ресурсы вычислительных систем, хотя, важность этой составляющей весьма очевидна. Например, один из принципов, лежащий в основе языка программирования C++, заключается в том, что не стоит платить за вещи, которые не используются [Мейерс2000-2]. Существуют языки и инструментальные средства, для которых время выполнения программ зависит от выбранного стиля. Если не использовать подобных знаний, то трудно написать эффективную программу. Кроме того, трансляторы могут по-разному отображать на память один и тот же программный объект.
На мой взгляд, визуальное проектирование, крупноблочное программирование, использование каркасов и языков с развитой идиоматической составляющей больше затрагивает не технику кодирования, а функциональные аспекты написания программ. Вместо мелких кирпичей используются крупные блоки и панели. Но и эти элементы надо объединять в конструкции. И вот здесь вновь начинает использоваться базовая техника, являющаяся предметом дальнейшего рассмотрения.
Эта базовая техника также не зависит от особенностей среды исполнения. Большинство компилируемых языков отличаются от языков сценариев функциональным составом. Это обусловлено тем, что интерпретация программы должна компенсироваться наличием более мощных встроенных операций. Однако техника написания скриптов мало чем отличается от техники кодирования, используемой в традиционных языках. А языки сценариев тоже могут поддерживать как одну, так и несколько парадигм программирования.
Особенности различных парадигм программирования, по ходу изложения, будем рассматривать на примере очень простой программы, осуществляющей различные манипуляции с заданным набором геометрических фигур, хранимых в едином контейнере. Исходными данными Задачи 1 будут следующие:
Естественно, что простой пример не позволяет рассмотреть все особенности проектирования сложных программных систем. Однако он обеспечивает сравнение различных парадигм программирования при решении рассматриваемых задач проектирования. Кроме того, следует отметить, что приведенный код не является образцом для подражания, так как в нем отсутствуют многие функции и проверки, необходимые в реально эксплуатируемой программе. Такие допущения объясняются учебным характером примера.
Код предполагается писать с использованием различных языков программирования, являющихся наиболее типичными при реализации рассматриваемых приемов. Там, где это специально не оговаривается, используется C++. Кроме реально существующих языков, по ходу изложения, будит вводиться гипотетические конструкции, которые, по моему мнению, могли бы использоваться в языках программирования. Однако, это ни в коей мере не предполагает, что я собираюсь тут же внедрять эти конструкции в уже существующие или вновь создаваемые языки.
[ <<< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Источники | >>> ]