converted to PDF by BoJIoc

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

программных компонент почти всегда труднее разработки конкретно требуемой программы.

∙Так как создание многократно используемых компонент затруднено, то окупаемость не достигается в пределах одного проекта. На самом деле стремление к модульности может даже снизить скорость реализации проекта. Немедленная

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

∙Так как применение многократно используемых компонент непосредственно не улучшает проект, программисты не имеют стимула бороться за многократное использование.

∙Так как каждая новая задача обычно требует специфической функциональности,

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

∙Многие программисты и администраторы подозрительно относятся к программам, которые не были разработаны в родных стенах. Такая осторожность называется синдромом «сделано не здесь». Так как сами администраторы гордятся своими командами, они, естественно, верят, что их программисты могут все сделать лучше, чем кто-либо.

∙Так как многие программисты недостаточно формально обучены или не держат руку на пульсе последних программных нововведений (таких, как ООП), они могут не знать о механизмах для разработки многократно используемого кода.

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

многократное использование неизбежно станет нормой разработки программного обеспечения.

Вот список недавно изданных книг, посвященных разработке многократно используемых компонент [Carroll 1995, McGregor 1992, Meyer 1994, Goldberg 1995].

Упражнения

∙Есть различные способы реализации структуры данных стек — например, с помощью списков или в виде массива. Предположим, мы имеем и класс списков List, и класс массивов Array. Для каждого из них проиллюстрируйте, как можно построить стек, используя и наследование, и композицию. Вам разрешается ввести какие угодно методы для базовых классов. Какая из техник реализации кажется вам более подходящей в данном случае?

∙Снова предположим, что мы имеем готовую структуру данных List и хотим построить абстракцию, представляющую собой упорядоченный список, в котором элементы вставляются в нужной последовательности, а не просто в начало списка.