Лицевая сторона

имя класса: stack сотрудники:

ответственность: нет

push

pop

empty

открытое поведение

оборотная сторона

состояние/описание

top

base_pointer

В процессе проектирования карточки уточняются и переписываются. Они становят­ся более детальными и похожими на набор заголовков функций-членов. Оборотная сторона карточки может использоваться для показа деталей реализации, включая отношения ISA, LIKEA и HASA.

Привлекательностью подобной схемы является ее гибкость. На самом деле на представляет собой процесс уточнения псевдокода, причем этот процесс может отра­жать личные представления проектировщиков. Число пересмотров и уровень дета­лизации и точности — это дело вкуса (Budd, 1991).

Диаграммы Вассермана-Пирчера восходят к модели «сущность-связь» (entity-relation) и структурному проектированию.

Location

x, y показывает

открытое

наследование

p (р означает

конструкторы public)

Point

x,у, color Point

Point

x,у, color Draw ^x color

Color

Комплексная интегрированная среда разработки ООП-кода, предлагаемая фирмой Interactive Development Environments (IDE), Сан-Франциско, Калифорния, исполь­зует приведенную выше схему. Проектирование программного обеспечения отобра­жено на следующих диаграммах.

Шаблоны проектирования на С++ от IDE

формальный

параметр

управления of1 e1 параметр исключения

выводом

виртуальная v имя функции

функция-члена а1 а2

е1 имя исключения

класс

формальные

lv1параметры ввода

ov2 и вывода данных

х формальный

защищеннаяο gp1 параметр

функция-член а3 а4 шаблона

шаблон класса

Уровень детализации таков, что из проекта могут быть автоматически получены за­глушки кода. Кроме того, одновременно можно проверить или сгенерировать доку­ментацию и стилевые правила.

Штампы проектирования

Повторное использование кода — вот основная тема современного программирова­ния. На первых парах оно ограничивалось простыми библиотеками функций, напри­мер математических из math.h или строковых из string.h. В ООП основной конструк­цией для повторного использования становятся класс или шаблон. Классы и шаблоны инкапсулируют код, пригодный для определенных проектов. Так, классы-итераторы из STL служат штампом проектирования (design pattern). С недавних пор концепция штампов проектирования стала очень популярной при обеспечении по­вторного использования в среднем масштабе (см. Gamma, 1994). Штамп проектиро­вания имеет четыре элемента:

Элементы штампа проектирования

1. Терминология штампа. Например, итератор.

2. Задача и условия. Например, перебор в контейнере.

3. Решение. Например, подобные указателям объекты с общим интерфейсом.

4. Оценка. Например, выбор между определением итератора на основе вектора и использованием собственного типа массива C++.

Штамп проектирования — это абстракция, которая предлагает подходящее решение для конкретной задачи программирования. Повторное использование часто не тре­бует больших затрат. Так происходит в случае с контейнерами STL и итераторными штампами проектирования, которые нуждаются лишь в инстанцировании. Иногда повторное использование все же дорого обходится, например, изобретение с нуля сбалансированного класса дерева с интерфейсом, соответствующим последователь­ным контейнерам STL.

Штампы проектирования в этой книге

1. Итератор. Например, vector: : iterator. Организует перебор в контейнере.

2. Композиция. Например, класс grad_student. Составляет сложные объекты из более простых.

3. Метод шаблонов. Например, шаблон quicksort ().

C++: критика

В какой-то степени C++ является версией 90-х годов языков PL/I (1965 г.) или Ada (1980 г.). C++ — результат предпринятой в среде профессиональных разработчиков попытки предложить почти универсальный язык программирования. Дефектом PL/1 было то, что он смешал в себе слишком много стилей — он объединил COBOL, FORTRAN и элементы ALGOL в одном языке. Недостатками Ada были его размер, сложность и неэффективность. У C++ есть проблемы с размером и сложностью, но очень важно то, что он основывается на существующих ресурсах и практике. Он также придает особое значение эффективности, иногда даже слишком большое.

Некоторых проблем C++, связанных со сложностью, можно избежать, придержива­ясь «идеологически правильных» взглядов на смысл тех или иных свойств языка. На­пример, чисто виртуальная функция может быть определена с исполняемым кодом:

class ABC {

public:

virtual void f( ) = 0;

};

void ABC::f( ) { cout << "чисто виртуальная f" << endl; }

//должна вызываться с уточненным именем: x.ABC::f( );

То, что такая конструкция допускается языком, выглядит эксцентрично. По идее же, чисто виртуальная функция используется для того, чтобы отложить определение.

Другие сложности языка принципиальны с точки зрения дизайна C++, например отсутствие сборки мусора (garbage collection). Существует несколько предложений на этот счет (см. Edelson, 1991, 1992, Boehm, 1988), и их реализация подтверждает, что сборка мусора может быть выполнена для большинства прикладных задач без ущерба для производительности. Большинство основных языков ООП, такие как Smalltalk, CLOS и Eiffel, поддерживают сборку мусора. Аргументом в пользу сборки мусора служит то, что такая встроенная возможность значительно облегчает задачу программисту. Потери памяти и ошибки указателей — вполне обычные проблемы, когда каждый класс предусматривает собственное управление памятью. Это очень сложные для выявления и отладки ошибки. Сборка мусора — хорошо известная тех­нология, так почему бы ее не использовать?

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

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

ООП требует от программиста искушенности. Искушенный

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

ООП делает клиентский код легче расширяемым и более простым. Для включе­ния локальных изменений в крупномасштабную систему без ее глобальных модифи­каций может быть использован полиморфизм. Минус — накладные расходы на этапе выполнения.

C++ предоставляет программисту инкапсуляцию с помощью классов, наследования и шаблонов. Инкапсуляция скрывает и локализует данные. Когда системы становятся больше и сложнее, нужда в ней все возрастает. Простой блочной структуры и инкапсуляции функций в таких языках, как FORTRAN и ALGOL, недостаточно. 70-е годы помогли нам понять необходимость модуля как единицы программирования. В 80-х мы поняли: модули должны быть логически согласованы, что должно поддер­живаться языком, причем они должны наследоваться друг от друга. Поддерживае­мые языком программирования инкапсуляция и родственные отношения приводят к укреплению дисциплины программирования. Искусство программирования заклю­чается в сочетании строгости и дисциплины с творчеством.

1Под дисциплиной программирования обычно понимают набор неофициальных (а часто и вовсе неписаных) правил, вытекающих не из формальных требований языка, а из общепринятых представлений о том, что есть «хорошая программа». — Примеч. перев.

1А производителя — от несанкционированного использования придуманных им алгорит­мов в продуктах других разработчиков. — Примеч.перев.

1WYSIWYG — What You See Is What You Get, «что видим, то и получим». Принцип, в соответствии с которым приложение (обычно текстовый или графический редактор) гаран­тирует, что пользователь, распечатав документ, получит именно то, что он видел в ходе ра­боты на экране. Зачастую, правда, пользователи утверждают, что их приложение построено по принципу WYSIWYNG — What You See Is What You Never Get, «что видим, то никогда не получим» — Примеч. перев.

1

1

1

1