Бертран Мейер - Основы объектно-ориентированного программирования
[x]. Совместимость. Если использовать хорошую современную ОО-библиотеку, то ее стиль повлияет, за счет естественного "процесса диффузии", на стиль разработки всего ПО. Это существенно помогает повысить качество программного продукта.
[x]. Инвестирование. Создание повторно используемого ПО позволяет сберечь плоды знаний и открытий лучших разработчиков, превращая временные ресурсы в постоянные.
Многие из тех, кто признает повторное использование желательным, имеют в виду лишь первый из факторов в этом списке, - повышение производительности. Но это не всегда самый важный вклад повторного использования в процесс разработки ПО. Повышение надежности, например, является не менее существенным фактором. Тоже можно сказать и об эффективности.
В этом отношении повторное использование можно рассматривать как особый показатель, отличающийся от других факторов, обсуждавшихся в лекции 1. Его улучшение дает возможность улучшить почти все остальные факторы качества ПО. А причина чисто экономическая: если элемент ПО служит не для одного, а для многих проектов, то экономически разумно использовать лучшие методы создания высококачественного ПО - формальную верификацию, всестороннюю оптимизацию. В обычных разработках от таких приемов зачастую отказываются как от ненужного излишества. Однако для повторно используемых компонентов аргументация существенно изменяется - улучшение всего лишь одного элемента может оказаться выгодным для тысяч разработок.
Конечно, эти рассуждения не являются совсем новыми - они отчасти представляют собой перенос на производство ПО тех идей, которые уже существенно затронули другие отрасли деятельности, когда они перешли от индивидуально изготовляемых изделий к индустрии массового производства. Изготовление чипа СБИС обходится значительно дороже, чем серийное изготовление простой специализированной схемы, но если он хорошо выполнен, то он проявит себя в бесчисленных компьютерных системах и повысит их качество благодаря всей вложенной в него раз и навсегда работе его конструкторов.
Потребители и производители повторно используемых программ
В приведенном выше списке преимуществ можно выделить две ситуации - использование профессиональных или собственных компонентов. Первые четыре элемента списка описывают ситуацию использования существующих, профессионально разработанных компонентов. Последний элемент списка характеризует повторное использование собственного программного продукта. Элемент списка - совместимость - относится к обоим случаям.
Такое разграничение достоинств отражает два аспекта повторного использования: точку зрения потребителя, пользующегося продукцией разработчиков компонент, и точку зрения производителя, обеспечивающего возможность повторного использования своих разработок.
Для разработчиков ПО, еще не имеющих большого опыта, следует быть потребителями компонентов. Принципиально невозможно сразу приступать к производству повторно используемых программ. Единственно возможный путь стать производителем - состоит в изучении и копировании уже существующих хороших образцов. Такой подход сразу принесет свои полезные плоды, поскольку в своих разработках вы воспользуетесь достоинствами этих компонентов.
Дорога к Повторному использованию
Станьте потребителем повторного использования, прежде чем пытаться стать его производителем.
Что следует повторно использовать?
Убедив себя в том, что Повторное использование - Это Хорошо, осталось выяснить, как же этого добиться?
Первый возникающий вопрос - на каком уровне следует осуществлять повторное использование: персонала, спецификаций, проектов, их образцов, исходного кода, компонентов или абстрактных модулей.
Повторное использование персонала
Наиболее просто повторно использовать разработчиков, что широко практикуется в промышленности. Переводя разработчиков ПО с одного проекта на другой, фирмы избегают потери накопленного ими ранее опыта и обеспечивают его достойное применение в новых разработках.
Ввиду высокой текучести программистских кадров возможности такого подхода ограничены.
Повторное использование проектов и спецификаций
Этот подход является, по существу, более организованной версией предыдущего - повторного использования знаний, умений и опыта. Как показало обсуждение вопроса о документации, само представление проекта как независимого программного продукта, имеющего собственный жизненный цикл, независимый от соответствующей реализации, кажется сомнительным, поскольку трудно гарантировать, что проект и его реализация будут оставаться совместимыми в процессе изменения системы ПО.
Таким образом, если повторно использовать только проект, то возникает риск повторного использования неправильно работающих или уже вышедших из употребления элементов.
Эти замечания можно отнести и к другому смежному виду повторного использования: повторному использованию спецификаций.
Среди разработчиков ПО долгое время бытовала идея о том, что единственно заслуживающим внимания является повторное использование лишь проектов и спецификаций. Эта идея весьма существенно препятствовала продвижению вперед, поскольку означала, что создание компонентов направлено на удовлетворение лишь несущественных потребностей и не решает истинно трудных проблем. Прежде эта точка зрения была преобладающей; преодолеть ее удалось благодаря объединенному воздействию теоретических доводов (соображений ОО-технологии) и практических достижений (успешной реализации повторно используемых компонентов).
Термин "преодолеть" здесь является, пожалуй, слишком сильным, поскольку, как это часто бывает в подобных спорах, свою долю в достижение полезного результата внесли обе стороны. Идея повторного использования проектов становится намного более интересной при использовании подхода (такого, как точка зрения на ОО-технологию, развиваемая в этой книге), который существенно устраняет разрыв между проектом и его реализацией. Тогда разница между модулем и проектом модуля (design for a module) является не принципиальной, а лишь количественной: проект модуля это просто модуль, отдельные фрагменты которого еще не полностью реализованы; а полностью реализованный модуль можно использовать, благодаря средствам абстрактного представления, в качестве проекта модуля. При таком подходе различие между повторным использованием модулей (рассматриваемым ниже) и повторным использованием проектов постепенно исчезает.
Образцы проектов (design patterns)
В середине девяностых годов специалистов привлекла идея образцов (или шаблонов) проектов. Образец - это архитектурный принцип, применимый во многих прикладных областях; следуя образцу можно построить решение некоторой проблемы.(Образец проекта с историей команд рассмотрен в лекции 3 курса "Основы объектно-ориентированного проектирования".)
Вот типичный пример, подробно обсуждаемый в одной из последующих лекций. Проблема: как снабдить интерактивную систему механизмом, позволяющим ее пользователям отменить ранее выполненную команду, если они решат, что она была нецелесообразной, и повторить выполнение отмененной команды, если они передумают. Образец: использовать класс COMMAND определенной структуры (которую мы в последующем рассмотрим) и связанный с ней "список истории". Будут рассмотрены и многие другие образцы проектов.
Одной из причин успешного внедрения идеи образца проекта явилось то, что это была не просто идея: книга4.1), в которой впервые было предложено это понятие, и последовавшие за ней издания содержали каталог непосредственно применимых образцов, которые читатели могли изучать и использовать.
Образцы проектов уже внесли существенный вклад в развитие ОО-технологии, и по мере публикации все новых образцов они помогут разработчикам пользоваться опытом своих предшественников и современников. Как же этот общий принцип приложить к проблеме повторного использования? Образцы проектов не должны внушать надежду на возвращение к уже упоминавшейся ранее мысли о том, что "все что нужно - это только повторно использовать проекты". Образец, который по-существу представляет собой лишь сценарий образца (book pattern), пусть даже самый лучший и универсальный, является только "учебным пособием", а не инструментальным средством повторного использования. Как-никак, а в течении трех последних десятилетий учебники по компьютерным наукам рассказывают об оптимизации реляционных баз данных, AVL-деревьях (сбалансированных деревьях Адельсона-Вельского и Ландиса), алгоритме быстрой сортировки (Quicksort) Хоара, алгоритме Дейкстры для поиска кратчайшего пути в графе, без какого-либо упоминания о том, что эти мет оды совершили прорыв в решении проблемы повторного использования. В определенном смысле, образцы, разработанные за последние несколько лет, являются лишь очередными дополнениями к набору стандартных приемов, используемых специалистами по разработке ПО. При таком понимании новым вкладом в ОО-технологию следует считать не идею образца, а сами предлагаемые образцы.
