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

В середине девяностых годов специалистов привлекла идея образцов(или шаблонов) проектов. Образец - это архитектурный принцип, применимый во многих прикладных областях; следуя образцу можно построить решение некоторой проблемы.(Образец проекта с историей команд рассмотрен в лекции 3курса "Основы объектно-ориентированного проектирования".)

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

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

Образцы проектов уже внесли существенный вклад в развитие ОО-технологии, и по мере публикации все новых образцов они помогут разработчикам пользоваться опытом своих предшественников и современников. Как же этот общий принцип приложить к проблеме повторного использования? Образцы проектов не должны внушать надежду на возвращение к уже упоминавшейся ранее мысли о том, что "все что нужно - это только повторно использовать проекты". Образец, который по-существу представляет собой лишь сценарий образца (book pattern), пусть даже самый лучший и универсальный, является только "учебным пособием", а не инструментальным средством повторного использования. Как-никак, а в течении трех последних десятилетий учебники по компьютерным наукам рассказывают об оптимизации реляционных баз данных, AVL-деревьях (сбалансированных деревьях Адельсона-Вельского и Ландиса), алгоритме быстрой сортировки (Quicksort) Хоара, алгоритме Дейкстры для поиска кратчайшего пути в графе, без какого-либо упоминания о том, что эти мет оды совершили прорыв в решении проблемы повторного использования. В определенном смысле, образцы, разработанные за последние несколько лет, являются лишь очередными дополнениями к набору стандартных приемов, используемых специалистами по разработке ПО. При таком понимании новым вкладом в ОО-технологию следует считать не идею образца, а сами предлагаемые образцы.

Обстоятельное рассмотрение проблемы образцов показывает, что эта точка зрения оказывается излишне ограниченной (См. "Программы с дырами", лекция 14). По-видимому, само понятие образца является действительно новым вкладом, даже если это еще не вполне осознанно. Но требуется дополнительная работа над образцами, чтобы выйти за пределы их чисто педагогической ценности. Удачный образец не может быть представлен лишь некоторым текстовым описанием - это должен быть компонент ПОили набор таких компонентов. На первый взгляд такая цель может представляться довольно отдаленной, поскольку многие из образцов являются настолько универсальными и абстрактными, что кажется невозможным реализовать их в виде программных модулей.

Но использование ОО-технологии обеспечивает радикальный вклад - она позволяет создавать повторно используемые модули, обладающие способностью изменяться. Они не будут "замороженными" элементами, а служат общими схемами, образцами, - здесь действительно уместен термин образецв полном смысле этого слова, они могут быть адаптированы к различным конкретным ситуациям. Это новое понятие мы называем классом, определяющим поведение (behavior class)(более образным является термин программы с дырами (programs with holes)). Это понятие, основанное на понятии отложенного (абстрактного) класса (deferred class), будет рассмотрено в последующих лекциях. Объединяя его с идей о группе компонентов, предназначенных для совместного функционирования - часто называемых каркасами (frameworks)или просто библиотеками- получаем замечательное средство, сочетающее повторное использование и способность к адаптации.

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