А. Александреску - Современное проектирование на C++ (1119444), страница 5

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

Все они внесли свой вклад в улучшение рукописи. Без них мне не удалось бы сделать и половины работы. Спасибо Грегу Комо (Огей Сотеац) за то, что он предоставил в мое распоряжение превосходный компилятор. В заключение я хотел бы поблаголарить всю мою семью и друзей за их постоянное поошрение и поддержку. РАЗРАБОТКАКЛАССОВ НА ОСНОВЕ СТРАТЕГИЙ В этой главе описываются понятия стратегии (ро11су) и классов стратегий (ро!гсу с1амеа), и!разошие важную раль в создании библиотек, эффективно обеспечивмоших повторное использование кола, Библиотека (ок) была задумана именно такой, Кратко говоря„ проектирование, основанное на стратегиях, позволяет создавать класс со сложным поведением из множества маленьких классов (называемых страеегиаии), каждый нз которых отвечает только за один функциональный или структурный аспект. Как следует из ее названия, стратегия устанавливает интерфейс, соответствуюший определенному свойству.

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

Класс впагтртг (глава 7) почти целиком сконструирован из стратегий. Механизм двойной диспетчеризации (г!овЫе-йзрагсл епй!пе), описанный в главе 11, использует стратегии лля выбора разных компромиссов, геализация обобшеннои "абстрактной фабрики" (Оапппа е! а!., 1995), приведенная в главе 9, применяет стратегию для выбора метода создания объектов. В этой главе описывается предназначение стратегий, рассматриваются детали их проектирования и приводятся советы, позволяюшие разложить класс на стратегии.

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

Каждый новый способ открывает новый мир. При выборе одного из решений возникает множество возможных вариантов, начиная с уровня системной архитектуры и заканчивая малейшими деталями кодирования. Таким образом, разработка программных систем заключается в выборе решений из гигантского числа вариантов. Рассмотрим простейший пример низкоуровневой разработки — интеллектуальные указатели (глава 7). Интеллектуальные указатели (этап роЫегз) представляют собой классы, которые могут быль как одно- так и многопоточными. Они могут использовать различные стратегии владения ресурсами, а также разные компромиссы между безопасностью и скоростью.

Кроме того, интеллектуальные указатели могут поддерживать или не подлерживать автоматическое преобразование в обычные указатели. Все эти свойства можно свободно комбинировать, причем обычно в конкретной области, лля которой предназначено программное обеспечение, наилучшим является лишь одно решение. Разнообразие методов создания программного обеспечения постоянно смущает начинающих разработчиков. Перед ними стоит конкретная задача. Что применить для ее успешного решения? События? Объекты? Наблюдатели? Обратные вызовы? Виртуальные классы? Шаблоны? Если абстрагироваться от конкретных деталей, разные решения окажутся эквивалентными.

В отличие от новичка, опытный разработчик программного обеспечения знает, кто добегает, и чаю — нет. Для каждой конкретной задачи существует множество методов решения. Они обладают своими преимушествами и недостатками, которые определяют, насколько тот или иной метод подходит для решения поставленной задачи. Решение, которое казалось вполне приемлемым на бумаге, на практике может оказаться ошибкой. Создавать программное обеспечение сложно, поскольку разработчик постоянно должен делать выбод. А в программировании„как и в жизни вообще, трудно сделать правильный выбор. ' Опытный разработчик знает, какой выбор велет к поставленной цели, в то время как новичок каждый раз делает шаг в неизвестность.

Опьпный архитектор программного обеспечения напоминает хорошего шахматиста: он видит на много ходов вперед. Для этого нужно долго учиться. Возможно поэтому гениальные программисты бывают очень молодыми, в то время как гениальные разработчики программного обеспечения обычно находятся в зрелом возрасте. Кроме головоломок, постоянно возникающих перед начинающими разработчиками, комбинаторная природа архитектурных решений доставляет много хлопот создателям библиотек. Для того чтобы реализовать библиотеку, пригодную для создания программного обеспечения„разработчик должен классифицировать и адаптировать множество типичных ситуаций. Библиотеку следует оставить открытой для модификаций, чтобы прикладной программист мог приспособить ее для своих нужд, создав конкретную программу.

Действительно, как упаковать гибкие, основательно разработанные компоненты в библиотеку" .Как предоставить пользователю возможность настраивать эти компоненты? Как преодолеть "проклятие выбора" с помощью кода, имеющего разумные размеры? Вот каким вопросам посвящена эта глава, да и вся книга в целом. 1.2. Недостатки универсального интерфейса Реализовать все под оболочкой универсального интерфейса — неудачное решение. Это объясняется следующими причинами, К основным негативным последствиям такого выбора относятся интеллектуальные издержки, огромный размер и неэффективность библиотеки. Гигантские классы очень непродуктивны, поскольку на их изучение нужно тратить большие усилия, они слиш- Часть!, Методы ком велики, а программы, использующие такие классы, работают намного медленнее, чем аналогичные программы, разработанные вручную. Однако едва ли не самой важной проблемой, связанной с использованием универсального интерфейса, является потеря безопасности статических типов (зщегс !уре за(е~у).

Одна из основных целей архитектуры любого программного обеспечения— воплощение некоторых аксиом "по определению". Например, нельзя одновременно создавать два объекта класса ззпй1етоп (глава 6) или объекты непересекающихся семейств (гйз)о!пс (аппйез) (глава 9). В идеале разработчик должен накладывать больщинспю ограничений еше на этапе компиляции. В большом всеобъемлющем интерфейсе очень трудно учесть все подобные ограничения, Обычно конкретные ограничения семантически соответствуют лишь части интерфейса. Это ведет к увеличению разрыва между гинтаксичегкой и семантической правильностью программ, использующих данную библиотеку. Рассмотрим, например, аспект реализации объекта класса Ыпо1 етоп, связанный с безопасностью работы в многопоточной среде.

Если библиотека полностью инкапсулирует потоковые свойства, то пользователь конкретной, непереносимой системы не может использовать библиотеку синглтонов, Если эта библиотека предоставляет поступ к основным незащищенным функциям, возникает опасность, что программист разрушит библиотеку, написав код, который будет синтаксически правильным, но семантически неверным. А что, если библиотека будет реализовывать разные проектные решения в виде разных классов более скромного размера? Каждый класс мог бы воплощать конкретное проектное решение. При использовании интеллектуальных указателей, например, естественно ожидать появления многочисленных реализаций: взпй1етоптЬгеадебвяагтртг, мц1т(т(згеадедвяагтртг, йеГсоиптебваагтртг, яе1ьзпкебваагтртг и т.п.

Для этого подхода характерен резкий рост количества разных вариантов проектных решений. Четыре упомянутых класса могут привести к появлению новых комбинаций, например, в виде класса ззпй1етпгеадег(яеФсоцптедвяагтртг. Преобразование типов приведет к еше большему количеству комбинаций, которые в конце концов выйдуг за рамки возможностей как программиста, так и пользователя библиотеки.

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

Следовательно, библиотеки, ориентированные на разработку программ, должны давать пользователю возможность формулировать свои собственные ограничения, а не навязывать встроенные. Раз и навсегда законсервированные проектные решения могут оказаться так же непригодными для библиотек, ориентированных на разработку программ, как, например, константы, явно заданные в обычных программах. Разумеется, наборы "наиболее популярных*' или "рекомендуемых" готовых решений вполне допустимы, если программист может изменять их по мере надобности. Эти проблемы иллюстрируют неблагоприятную ситуацию, сложившуюся в области разработки библиотек. Большого количества низкоуровневых универсальных и специализированных библиотек, облегчающих разработку программ, т.е, структур высо- Глава 1. Разработка классов на основе стратегий 27 кого уровня, практически нет. Это парадоксальная ситуация, поскольку любое нетривиальное приложение воллошает некие проектные решения.

Следовательно, библиотеки, ориентированные на создание программ, должны были бы найти применение в большинстве приложений. Этот пробел попытались заполнить специальные среды разработки (ВнгпечогЬ). Однако они в основном предназначены лля того, чтобы связать приложение с конкретным проектным решением, а вовсе не для того, чтобы помочь пользователю выбрать и настроить свой проект. Если программист стремится реализовать свой оригинальный проект, он должен начинать все "с нуля", созданая классы, функции и т.п.

1.3. Опасно ли множественное наследование? Рассмотрим класс темрогагу5есгетагу, производный от классов 5есгетагу и теагрогагу одновременно'. Класс теагрогагунесгетагу обладает свойствами обоих классов, описыная как секретаря, так и временно нанятого служашего. Кроме того, он может иметь и свои особенности. Это наталкивает на мысль, что множественное наследонание может помочь нам справиться с зкспоненциальным ростом количесгна проектных регпений с помошью малого числа тшагельно подобранных базовых кпассов. В таком случае пользователь смог бы создать класс для многопоточного интеллектуального указателя„подсчитываюшего количество ссылок (ге(егепсе-соцпгег) згпал роп(ег), выведя его из некоторого класса вазенмагтптг и классов мц1т(тпгеа0ег! и яебсоиптег!.

Характеристики

Список файлов книги