Страница:
проваливающимся проектам.
Итак, допустим необходимо создать машину среднего размера с
четырьмя дверцами и достаточно мощным мотором. Очевидно, что
на первом этапе проекта не следует начинать проектирование машины
(и всех ее компонентов) с нуля. Хотя программист или разработчик
программного обеспечения в подобных обстоятельствах поступит именно
так.
На первом этапе надо выяснить, какие компоненты доступны на
вашем собственном складе и какие можно получить от надежных
поставщиков. Найденные таким образом компоненты не обязательно
в точности подойдут для новой машины. Всегда требуется подгонка
компонентов. Может быть даже потребуется изменить характеристики
"следующей версии" выбранных компонентов, чтобы сделать их
пригодными для проекта. Например, может существовать вполне пригодный
мотор, вырабатывающий немного меньшую мощность.Тогда
или вы, или поставщик мотора должны предложить, не изменяя общего
описания проекта, в качестве компенсации дополнительный
зарядный генератор. Заметим, что сделать это,"не изменяя общего описания
проекта", маловероятно, если только само описание не приспособлено
к определенной подгонке. Обычно подобная
подгонка требует кооперации между вами и поставщиком моторов.
Сходные вопросы возникают и у программиста или разработчика
программного обеспечения. Здесь подгонку обычно облегчает эффективное
использование производных классов. Но не рассчитывайте провести
произвольные расширения в проекте без определенного предвидения
или кооперации с создателем таких классов.
Когда исчерпается набор подходящих стандартных компонентов,
проектировщик машины не спешит заняться проектированием новых
оптимальных компонентов для своей машины. Это было бы слишком
расточительно. Допустим, что не нашлось подходящего блока
кондиционирования воздуха, зато есть свободное пространство, имеющее
форму буквы L, в моторном отсеке. Возможно решение разработать
блок кондиционирования указанной формы. Но вероятность того, что
блок подобной странной формы будет использоваться в машинах другого
типа (даже после значительной подгонки), крайне низка. Это означает,
что наш проектировщик машины не сможет разделить затраты на
производство такого блока с создателями машин другого типа, а значит
время жизни этого блока коротко. Поэтому стоит спроектировать блок,
который найдет более широкое применение, т.е. разработать
разумный проект блока, более приспособленный для подгонки, чем наше
L-образное чудище. Возможно, это потребует больших усилий, и даже
придется для приспособления более универсального блока изменить
общее описание проекта машины. Поскольку новый блок разрабатывался
для более общего применения, чем наше L-образное чудище,
предположительно, для него потребуется некоторая подгонка, чтобы
полностью удовлетворить наши пересмотренные запросы.
Подобная же альтернатива возникает и у программиста или разработчика
программного обеспечения: вместо того, чтобы создать программу,
привязанную к конкретному проекту, разработчик может спроектировать
новую достаточно универсальную программу, которая будет иметь
хорошие шансы стать стандартной в определенной области.
Наконец, когда мы прошлись по всем стандартным компонентам,
составляется "окончательное" общее описание проекта. Несколько
специально разработанных средств указываются как возможные. Вероятно,
в следующем году придется для новой модели повторить наши шаги,
и как раз эти специальные средства придется переделать или выбросить.
Как ни печально, но опыт традиционно проектировавшихся программ
показывает, что лишь несколько частей системы можно выделить в
отдельные компоненты и лишь несколько из них пригодны вне
данного проекта.
Мы не пытаемся утверждать, что все разработчики машин
действуют столь разумно, как в приведенном примере, а разработчики
программ совершают все указанные ошибки. Утверждается, что указанная
методика разработки машин применима и для программного обеспечения.
Так, в этой и следующей главах даны приемы использования ее для С++.
Тем не менее можно сказать, что сама природа программирования
способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5).
В разделе 11.4.3 опровергается профессиональное предубеждение против
использования описанной здесь модели проектирования.
Заметим, что модель развития программного обеспечения хорошо
применима только в расчете на большие сроки. Если ваш горизонт
сужается до времени выдачи очередной версии, нет смысла создавать
и поддерживать функционирование стандартных компонентов. Это
просто приведет к излишним накладным расходам. Наша модель
рассчитана на организации со временем жизни, за которое проходит
несколько проектов, и с размерами, которые позволяют нести
дополнительные расходы и на средства проектирования, программирования,
и на сопровождение проектов, и на повышение квалификации разработчиков,
программистов и менеджеров. Фактически это эскиз некоторой фабрики по
производству программ. Как ни удивительно, она только масштабом
отличается от действий лучших программистов, которые для повышения своей
производительности в течении лет накапливали запас приемов и методов
проектирования, создавали инструменты и библиотеки. Похоже, что
большинство организаций просто не умеет воспользоваться достижениями
лучших сотрудников, как из-за отсутствия предвидения, так и по
неспособности применить эти достижения в достаточно широком
объеме.
Все-таки неразумно требовать, чтобы "стандартные компоненты"
были стандартными универсально. Существует лишь малое число
международных стандартных библиотек, а в своем большинстве компоненты
окажутся стандартными только в пределах страны, отрасли, компании,
производственной цепочки, отдела или области приложения и т.д.
Просто мир слишком велик, чтобы универсальный стандарт
всех компонентов и средств был реальной или желанной целью проекта.
Каковы самые общие цели проектирования? Конечно, простота, но в чем
критерий простоты? Поскольку мы считаем, что проект должен развиваться
во времени, т.е. система будет расширяться, переноситься,
настраиваться и, вообще, изменяться массой способов, которые невозможно
предусмотреть, необходимо стремиться к такой системе проектирования
и реализации, которая была бы простой с учетом, что она будет
меняться многими способами. На самом деле, практично допустить,
что сами требования к системе будут меняться неоднократно за период
от начального проекта до выдачи первой версии системы.
Вывод таков: система должна проектироваться максимально простой
при условии, что она будет подвергаться серии изменений. Мы должны
проектировать в расчете на изменения, т.е. стремиться к
- гибкости,
- расширяемости и
- переносимости
Лучшее решение - выделить части системы, которые вероятнее всего будут
меняться, в самостоятельные единицы, и предоставить программисту или
разработчику гибкие возможности для модификаций таких единиц. Это
можно сделать, если выделить ключевые для данной задачи понятия
и предоставить класс, отвечающий за всю информацию, связанную с
отдельным понятием (и только с ним). Тогда изменение будет затрагивать
только определенный класс. Естественно, такой идеальный способ
гораздо легче описать, чем воплотить.
Рассмотрим пример: в задаче моделирования метеорологических
объектов нужно представить дождевое облако. Как это сделать?
У нас нет общего метода изображения облака, поскольку его вид зависит
от внутреннего состояния облака, а оно может быть задано только
самим облаком.
Первое решение: пусть облако изображает себя само. Оно подходит
для многих ограниченных приложений. Но оно не является достаточно
общим, поскольку существует много способов представления облака:
детальная картина, набросок очертаний, пиктограмма, карта и т.п.
Другими словами, вид облака определяется как им самим, так и его
окружением.
Второе решение заключается в том, чтобы предоставить самому облаку
для его изображения сведения о его окружении. Оно годится для
большего числа случаев. Однако и это не общее решение. Если мы
предоставляем облаку сведения об его окружении, то нарушаем основной
постулат, который требует, чтобы класс отвечал только за одно
понятие, и каждое понятие воплощалось определенным классом.
Может оказаться невозможным предложить согласованное определение
"окружения облака", поскольку, вообще говоря, как выглядит облако
зависит от самого облака и наблюдателя. Чем представляется облако
мне, сильно зависит от того, как я смотрю на него: невооруженным
глазом, с помощью поляризационного фильтра, с помощью метеорадара и т.д.
Помимо наблюдателя и облака следует учитывать и "общий фон", например,
относительное положение солнца. К дальнейшему усложнению картины
приводит добавление новых объектов типа других облаков, самолетов.
Чтобы сделать задачу разработчика практически неразрешимой, можно
добавить возможность одновременного существования нескольких
наблюдателей.
Третье решение состоит в том, чтобы облако, а также и другие
объекты, например, самолеты или солнце, сами описывали себя по
отношению к наблюдателю. Такой подход обладает достаточной
общностью, чтобы удовлетворить большинство запросовЬ. Однако,
он может привести к значительному усложнению и большим накладным
расходам при выполнении. Как, например, добиться того, чтобы
наблюдатель понимал описания, произведенные облаком или другими
объектами?
Ь Даже эта модель будет, по всей видимости, не достаточной для таких
предельных случаев, как графика с высокой степенью разрешимости.
Я думаю, что для получения очень детальной картины нужен другой
уровень абстракции.
Дождевые облака - это не тот объект, который часто встретишь
в программах, но объекты, участвующие в различных операциях ввода
и вывода, встречаются часто. Поэтому можно считать пример с облаком
пригодным для программирования вообще и для разработки библиотек
в частности. Логически схожий пример в С++ представляют манипуляторы,
которые используются для форматирования вывода в потоковом
вводе-выводе ($$10.4.2). Заметим, что третье решение не есть "верное
решение", это просто более общее решение. Разработчик должен
сбалансировать различные требования системы, чтобы найти уровень
общности и абстракции, пригодный для данной задачи в данной области.
Золотое правило: для программы с долгим сроком жизни правильным
будет самый общий уровень абстракции, который вам еще понятен и
который вы можете себе позволить, но не обязательно абсолютно
общий. Обобщение, выходящее за пределы данного проекта и
понятия людей, в нем участвующих, может принести вред, т.е.
привести к задержкам, неприемлемым характеристикам, неуправляемым
проектам и просто к провалу.
Чтобы использование указанных методов было экономично и
поддавалось управлению, проектирование и управление должно
учитывать повторное использование, о чем говорится в $$11.4.1 и
не следует совсем забывать об эффективности (см. $$11.3.7).
Рассмотрим проектирование отдельного класса. Обычно это не лучший
метод. Понятия не существуют изолированно, наоборот, понятие
определяется в связи с другими понятиями. Аналогично и класс не
существует изолированно, а определяется совместно с множеством
связанных между собой классов. Это множество часто называют
библиотекой классов или компонентом. Иногда все классы компонента
образуют единую иерархию, иногда это не так (см. $$12.3).
Множество классов компонента бывают объединены некоторым логическим
условием, иногда это - общий стиль программирования или описания,
иногда - предоставляемый сервис. Компонент является единицей
проектирования, документации, права собственности и,
часто, повторного использования.
Это не означает, что если вы используете один класс компонента, то
должны разбираться во всех и уметь применять все классы компонента или
должны подгружать к вашей программе модули всех классов компонента. В
точности наоборот, обычно стремятся обеспечить, чтобы использование
класса вело к минимуму накладных расходов: как машинных ресурсов,
так и человеческих усилий. Но для использования любого класса
компонента нужно понимать логическое условие, которое его
определяет (можно надеяться, что оно предельно ясно изложено в
документации), понимать соглашения и стиль, примененный в процессе
проектирования и описания компонента, и доступный сервис (если он
есть).
Итак, перейдем к способам проектирования компонента. Поскольку
часто это непростая задача, имеет смысл разбить ее на шаги и,
сконцентрировавшись на подзадачах, дать полное и последовательное
описание. Обычно нет единственно правильного способа разбиения.
Тем не менее, ниже приводится описание последовательности шагов,
которая пригодилась в нескольких случаях:
[1] Определить понятие / класс и установить основные связи
между ними.
[2] Уточнить определения классов, указав набор операций для
каждого.
[a] Провести классификацию операций. В частности уточнить
необходимость построения, копирования и уничтожения.
[b] Убедиться в минимальности, полноте и удобстве.
[3] Уточнить определения классов, указав их зависимость от
других классов.
[a] Наследование.
[b] Использование зависимостей.
[4] Определить интерфейсы классов.
[a] Поделить функции на общие и защищенные.
[b] Определить точный тип операций класса.
Отметим, что это шаги итеративного процесса. Обычно для получения
проекта, который можно уверенно использовать для первичной реализации
или повторной реализации, нужно несколько раз проделать
последовательность шагов. Одним из преимуществ глубокого анализа и
предложенной здесь абстракции данных оказывается относительная
легкость, с которой можно перестроить взаимоотношения классов
даже после программирования каждого класса. Хотя это никогда не
бывает просто.
Далее следует приступить к реализации классов, а затем
вернуться, чтобы оценить проект, исходя из опыта реализации.
Рассмотрим эти шаги в отдельности.
Определите понятия/классы и установите основные связи между ними.
Главное в хорошем проекте - прямо отразить какое-либо понятие
"реальности", т.е. уловить понятие из области приложения классов,
представить взаимосвязь между классами строго определенным способом,
например, с помощью наследования, и повторить эти действия на
разных уровнях абстракции. Но как мы можем уловить эти понятия?
Как на практике решить, какие нам нужны классы?
Лучше поискать ответ в самой области приложения, чем рыться
в программистском хранилище абстракций и понятий. Обратитесь к тому,
кто стал экспертом по работе в некогда сделанной системе, а также
к тому, кто стал критиком системы, пришедшей ей на смену. Запомните
выражения того и другого.
Часто говорят, что существительные играют роль классов и объектов,
используемых в программе, это действительно так. Но это только начало.
Далее, глаголы могут представлять операции над объектами или
обычные (глобальные) функции, вырабатывающие новые значения, исходя
из своих параметров, или даже классы. В качестве примера
можно рассматривать функциональные объекты, описанные в $$10.4.2.
Такие глаголы, как "повторить" или "совершить" (commit) могут быть
представлены итеративным объектом или объектом, представляющим
операцию выполнения программы в базах данных.
Даже прилагательные можно успешно
представлять с помощью классов, например, такие, как "хранимый",
"параллельный", "регистровый", "ограниченный". Это могут быть классы,
которые помогут разработчику или программисту, задав виртуальные
базовые классы, специфицировать и выбрать нужные свойства для
классов, проектируемых позднее.
Лучшее средство для поиска этих понятий / классов - грифельная
доска, а лучший метод первого уточнения - это беседа со специалистами
в области приложения или просто с друзьями. Обсуждение необходимо,
чтобы создать начальный жизнеспособный словарь терминов и понятийную
структуру. Мало кто может сделать это в одиночку. Обратитесь к [1],
чтобы узнать о методах подобных уточнений.
Не все классы соответствуют понятиям из области приложения.
Некоторые могут представлять ресурсы системы или абстракции
периода реализации (см. $$12.2.1).
Взаимоотношения, о которых мы говорим, естественно устанавливаются
в области приложения или (в случае повторных проходов по шагам
проектирования) возникают из последующей работы над структурой классов.
Они отражают наше понимание основ области приложения. Часто они
являются классификацией основных понятий. Пример такого отношения:
машина с выдвижной лестницей есть грузовик, есть пожарная машина,
есть движущееся средство.
В $$11.3.3.2 и $$11.3.3.5 предлагается некоторая точка зрения на
классы и иерархию классов, если необходимо улучшить их структуру.
Уточните определения классов, указав набор операций для каждого.
В действительности нельзя разделить процессы определения классов и
выяснения того, какие операции для них нужны. Однако, на практике
они различаются, поскольку при определении классов внимание
концентрируется на основных понятиях, не останавливаясь
на программистских вопросах их реализации, тогда как при определении
операций прежде всего сосредотачивается на том, чтобы задать полный и
удобный набор операций. Часто бывает слишком трудно совместить оба
подхода, в особенности, учитывая, что связанные классы надо
проектировать одновременно.
Возможно несколько подходов к процессу определения набора операций.
Предлагаем следующую стратегию:
[1] Рассмотрите, каким образом объект класса будет создаваться,
копироваться (если нужно) и уничтожаться.
[2] Определите минимальный набор операций, который необходим
для понятия, представленного классом.
[3] Рассмотрите операции, которые могут быть добавлены для удобства
записи, и включите только несколько действительно важных.
[4] Рассмотрите, какие операции можно считать тривиальными, т.е.
такими, для которых класс выступает в роли интерфейса для
реализации производного класса.
[5] Рассмотрите, какой общности именования и функциональности
можно достигнуть для всех классов компонента.
Очевидно, что это - стратегия минимализма. Гораздо проще добавлять
любую функцию, приносящую ощутимую пользу, и сделать все операции
виртуальными. Но, чем больше функций, тем больше вероятность, что
они не будут использоваться, наложат определенные ограничения на
реализацию и затруднят эволюцию системы. Так, функции, которые
могут непосредственно читать и писать в переменную состояния объекта
из класса, вынуждают использовать единственный способ реализации и
значительно сокращают возможности перепроектирования. Такие функции
снижают уровень абстракции от понятия до его конкретной реализации.
К тому же добавление функций добавляет работы программисту и
даже разработчику, когда он вернется к проектированию. Гораздо
легче включить в интерфейс еще одну функцию, как только
установлена потребность в ней, чем удалить ее оттуда, когда уже
она стала привычной.
Причина, по которой мы требуем явного принятия решения о
виртуальности данной функции, не оставляя его на стадию реализации,
в том, что, объявив функцию виртуальной, мы существенно повлияем
на использование ее класса и на взаимоотношения этого класса с
другими. Объекты из класса, имеющего хотя бы одну виртуальную
функцию, требуют нетривиального распределения памяти, если сравнить
их с объектами из таких языков как С или Фортран. Класс с хотя бы
одной виртуальной функцией по сути выступает в роли интерфейса
по отношению к классам, которые "еще могут быть определены", а
виртуальная функция предполагает зависимость от классов, которые
"еще могу быть определены" (см. $$12.2.3)
Отметим, что стратегия минимализма требует, пожалуй, больших
усилий со стороны разработчика.
При определении набора операций больше внимания следует уделять
тому, что надо сделать, а не тому, как это делать.
Иногда полезно классифицировать операции класса по тому,
как они работают с внутренним состоянием объектов:
- Базовые операции: конструкторы, деструкторы, операции копирования.
- Селекторы: операции, не изменяющие состояния объекта.
- Модификаторы: операции, изменяющие состояние объекта.
- Операции преобразований, т.е. операции порождающие объект
другого типа, исходя из значения (состояния) объекта, к которому
они применяются.
- Повторители: операции, которые открывают доступ к объектам класса
или используют последовательность объектов.
Это не есть разбиение на ортогональные группы операций. Например,
повторитель может быть спроектирован как селектор или модификатор.
Выделение этих групп просто предназначено помочь в процессе
проектирования интерфейса класса. Конечно, допустима и другая
классификация. Проведение такой классификации особенно полезно для
поддержания непротиворечивости между классами в рамках одного
компонента.
В языке С++ есть конструкция, помогающая заданию селекторов и
модификаторов в виде функции-члена со спецификацией const и без нее.
Кроме того, есть средства, позволяющие явно задать конструкторы,
деструкторы и функции преобразования. Операция копирования реализуется
с помощью операций присваивания и конструкторов копирования.
Уточните определение классов, указав их зависимости от других классов.
Различные виды зависимостей обсуждаются в $$12.2. Основными по
отношению к проектированию следует считать отношения наследования
и использования. Оба предполагают понимание того, что значит для
класса отвечать за определенное свойство системы. Отвечать за что-либо
не означает, что класс должен содержать в себе всю информацию, или,
что его функции-члены должны сами проводить все необходимые операции.
Как раз наоборот, каждый класс, имеющий определенный уровень
ответственности, организует работу, перепоручая ее в виде
подзадач другим классам, которые имеют меньший уровень ответственности.
Но надо предостеречь, что злоупотребление этим приемом приводит
к неэффективным и плохо понимаемым проектам, поскольку
происходит размножение классов и объектов до такой степени, что
вместо реальной работы производится только серия запросов на
ее выполнение. То, что можно сделать в данном месте, следует
сделать.
Необходимость учесть отношения наследования и использования
на этапе проектирования (а не только в процессе реализации) прямо
вытекает из того, что классы представляют определенные понятия.
Отсюда также следует, что именно компонент (т.е. множество
связанных классов), а не отдельный класс, являются единицей
проектирования.
Определите интерфейсы классов. На этой стадии проектирования не нужно
рассматривать приватные функции. Вопросы реализации, возникающие на
стадии проектирования, лучше всего обсуждать на шаге 3 при
рассмотрении различных зависимостей. Более того, существует
золотое правило: если класс не допускает по крайней мере двух
существенно отличающихся реализаций, то что-то явно не в порядке с этим
классом, это просто замаскированная реализация, а не представление
абстрактного понятия. Во многих случаях для ответа на вопрос:
"Достаточно ли интерфейс класса независим от реализации?"- надо
указать, возможна ли для класса схема ленивых вычислений.
Отметим, что общие базовые классы и друзья (friend) являются
частью общего интерфейса класса (см. $$5.4.1 и $$12.4). Полезным
упражнением может быть определение раздельного интерфейса для
классов-наследников и всех остальных классов с помощью разбиения
интерфейса на общую и закрытые части.
Именно на этом шаге следует продумать и описать точные определения
типов аргументов. В идеале желательно иметь максимальное число
интерфейсов со статическими типами, относящимися к области приложения
(см. $$12.1.3 и $$12.4).
При определении интерфейсов следует обратить внимание на те
классы, где набор операций представлен более, чем на одном уровне
абстракции. Например, в классе file у некоторых функций-членов
аргументы имеют тип file_descriptor (дескриптор_файла), а у других
аргументы - строка символов, которая обозначает имя файла.
Операции с file_descriptor работают на другом уровне (меньшем)
абстракции, чем операции с именем файла, так что даже странно,
что они относятся к одному классу. Возможно, было бы лучше иметь
два класса: один представляет понятие дескриптора файла, а
другой - понятие имени файла. Обычно все операции класса должны
представлять понятия одного уровня абстракции. Если это не так,
то стоит подумать о реорганизации и его, и связанных с ним классов.
Шаги 1 и 3 требуют исследования классов и их иерархии, чтобы
убедиться, что они адекватно отвечают нашим требованиям. Обычно
это не так, и приходится проводить перестройку для улучшения
структуры, проекта или реализации.
Самая типичная перестройка иерархии классов состоит в выделении
общей части двух классов в новый класс или в разбиении класса на два
новых. В обоих случаях в результате получится три класса:
базовый класс и два
производных. Когда следует проводить такую перестройку? Каковы
общие показания, что такая перестройка будет полезной?
К сожалению нет простого и универсального ответа на эти
вопросы. Это и не удивительно, поскольку то, что предлагается,
не является мелочью при реализации, а изменяет основные
Итак, допустим необходимо создать машину среднего размера с
четырьмя дверцами и достаточно мощным мотором. Очевидно, что
на первом этапе проекта не следует начинать проектирование машины
(и всех ее компонентов) с нуля. Хотя программист или разработчик
программного обеспечения в подобных обстоятельствах поступит именно
так.
На первом этапе надо выяснить, какие компоненты доступны на
вашем собственном складе и какие можно получить от надежных
поставщиков. Найденные таким образом компоненты не обязательно
в точности подойдут для новой машины. Всегда требуется подгонка
компонентов. Может быть даже потребуется изменить характеристики
"следующей версии" выбранных компонентов, чтобы сделать их
пригодными для проекта. Например, может существовать вполне пригодный
мотор, вырабатывающий немного меньшую мощность.Тогда
или вы, или поставщик мотора должны предложить, не изменяя общего
описания проекта, в качестве компенсации дополнительный
зарядный генератор. Заметим, что сделать это,"не изменяя общего описания
проекта", маловероятно, если только само описание не приспособлено
к определенной подгонке. Обычно подобная
подгонка требует кооперации между вами и поставщиком моторов.
Сходные вопросы возникают и у программиста или разработчика
программного обеспечения. Здесь подгонку обычно облегчает эффективное
использование производных классов. Но не рассчитывайте провести
произвольные расширения в проекте без определенного предвидения
или кооперации с создателем таких классов.
Когда исчерпается набор подходящих стандартных компонентов,
проектировщик машины не спешит заняться проектированием новых
оптимальных компонентов для своей машины. Это было бы слишком
расточительно. Допустим, что не нашлось подходящего блока
кондиционирования воздуха, зато есть свободное пространство, имеющее
форму буквы L, в моторном отсеке. Возможно решение разработать
блок кондиционирования указанной формы. Но вероятность того, что
блок подобной странной формы будет использоваться в машинах другого
типа (даже после значительной подгонки), крайне низка. Это означает,
что наш проектировщик машины не сможет разделить затраты на
производство такого блока с создателями машин другого типа, а значит
время жизни этого блока коротко. Поэтому стоит спроектировать блок,
который найдет более широкое применение, т.е. разработать
разумный проект блока, более приспособленный для подгонки, чем наше
L-образное чудище. Возможно, это потребует больших усилий, и даже
придется для приспособления более универсального блока изменить
общее описание проекта машины. Поскольку новый блок разрабатывался
для более общего применения, чем наше L-образное чудище,
предположительно, для него потребуется некоторая подгонка, чтобы
полностью удовлетворить наши пересмотренные запросы.
Подобная же альтернатива возникает и у программиста или разработчика
программного обеспечения: вместо того, чтобы создать программу,
привязанную к конкретному проекту, разработчик может спроектировать
новую достаточно универсальную программу, которая будет иметь
хорошие шансы стать стандартной в определенной области.
Наконец, когда мы прошлись по всем стандартным компонентам,
составляется "окончательное" общее описание проекта. Несколько
специально разработанных средств указываются как возможные. Вероятно,
в следующем году придется для новой модели повторить наши шаги,
и как раз эти специальные средства придется переделать или выбросить.
Как ни печально, но опыт традиционно проектировавшихся программ
показывает, что лишь несколько частей системы можно выделить в
отдельные компоненты и лишь несколько из них пригодны вне
данного проекта.
Мы не пытаемся утверждать, что все разработчики машин
действуют столь разумно, как в приведенном примере, а разработчики
программ совершают все указанные ошибки. Утверждается, что указанная
методика разработки машин применима и для программного обеспечения.
Так, в этой и следующей главах даны приемы использования ее для С++.
Тем не менее можно сказать, что сама природа программирования
способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5).
В разделе 11.4.3 опровергается профессиональное предубеждение против
использования описанной здесь модели проектирования.
Заметим, что модель развития программного обеспечения хорошо
применима только в расчете на большие сроки. Если ваш горизонт
сужается до времени выдачи очередной версии, нет смысла создавать
и поддерживать функционирование стандартных компонентов. Это
просто приведет к излишним накладным расходам. Наша модель
рассчитана на организации со временем жизни, за которое проходит
несколько проектов, и с размерами, которые позволяют нести
дополнительные расходы и на средства проектирования, программирования,
и на сопровождение проектов, и на повышение квалификации разработчиков,
программистов и менеджеров. Фактически это эскиз некоторой фабрики по
производству программ. Как ни удивительно, она только масштабом
отличается от действий лучших программистов, которые для повышения своей
производительности в течении лет накапливали запас приемов и методов
проектирования, создавали инструменты и библиотеки. Похоже, что
большинство организаций просто не умеет воспользоваться достижениями
лучших сотрудников, как из-за отсутствия предвидения, так и по
неспособности применить эти достижения в достаточно широком
объеме.
Все-таки неразумно требовать, чтобы "стандартные компоненты"
были стандартными универсально. Существует лишь малое число
международных стандартных библиотек, а в своем большинстве компоненты
окажутся стандартными только в пределах страны, отрасли, компании,
производственной цепочки, отдела или области приложения и т.д.
Просто мир слишком велик, чтобы универсальный стандарт
всех компонентов и средств был реальной или желанной целью проекта.
Каковы самые общие цели проектирования? Конечно, простота, но в чем
критерий простоты? Поскольку мы считаем, что проект должен развиваться
во времени, т.е. система будет расширяться, переноситься,
настраиваться и, вообще, изменяться массой способов, которые невозможно
предусмотреть, необходимо стремиться к такой системе проектирования
и реализации, которая была бы простой с учетом, что она будет
меняться многими способами. На самом деле, практично допустить,
что сами требования к системе будут меняться неоднократно за период
от начального проекта до выдачи первой версии системы.
Вывод таков: система должна проектироваться максимально простой
при условии, что она будет подвергаться серии изменений. Мы должны
проектировать в расчете на изменения, т.е. стремиться к
- гибкости,
- расширяемости и
- переносимости
Лучшее решение - выделить части системы, которые вероятнее всего будут
меняться, в самостоятельные единицы, и предоставить программисту или
разработчику гибкие возможности для модификаций таких единиц. Это
можно сделать, если выделить ключевые для данной задачи понятия
и предоставить класс, отвечающий за всю информацию, связанную с
отдельным понятием (и только с ним). Тогда изменение будет затрагивать
только определенный класс. Естественно, такой идеальный способ
гораздо легче описать, чем воплотить.
Рассмотрим пример: в задаче моделирования метеорологических
объектов нужно представить дождевое облако. Как это сделать?
У нас нет общего метода изображения облака, поскольку его вид зависит
от внутреннего состояния облака, а оно может быть задано только
самим облаком.
Первое решение: пусть облако изображает себя само. Оно подходит
для многих ограниченных приложений. Но оно не является достаточно
общим, поскольку существует много способов представления облака:
детальная картина, набросок очертаний, пиктограмма, карта и т.п.
Другими словами, вид облака определяется как им самим, так и его
окружением.
Второе решение заключается в том, чтобы предоставить самому облаку
для его изображения сведения о его окружении. Оно годится для
большего числа случаев. Однако и это не общее решение. Если мы
предоставляем облаку сведения об его окружении, то нарушаем основной
постулат, который требует, чтобы класс отвечал только за одно
понятие, и каждое понятие воплощалось определенным классом.
Может оказаться невозможным предложить согласованное определение
"окружения облака", поскольку, вообще говоря, как выглядит облако
зависит от самого облака и наблюдателя. Чем представляется облако
мне, сильно зависит от того, как я смотрю на него: невооруженным
глазом, с помощью поляризационного фильтра, с помощью метеорадара и т.д.
Помимо наблюдателя и облака следует учитывать и "общий фон", например,
относительное положение солнца. К дальнейшему усложнению картины
приводит добавление новых объектов типа других облаков, самолетов.
Чтобы сделать задачу разработчика практически неразрешимой, можно
добавить возможность одновременного существования нескольких
наблюдателей.
Третье решение состоит в том, чтобы облако, а также и другие
объекты, например, самолеты или солнце, сами описывали себя по
отношению к наблюдателю. Такой подход обладает достаточной
общностью, чтобы удовлетворить большинство запросовЬ. Однако,
он может привести к значительному усложнению и большим накладным
расходам при выполнении. Как, например, добиться того, чтобы
наблюдатель понимал описания, произведенные облаком или другими
объектами?
Ь Даже эта модель будет, по всей видимости, не достаточной для таких
предельных случаев, как графика с высокой степенью разрешимости.
Я думаю, что для получения очень детальной картины нужен другой
уровень абстракции.
Дождевые облака - это не тот объект, который часто встретишь
в программах, но объекты, участвующие в различных операциях ввода
и вывода, встречаются часто. Поэтому можно считать пример с облаком
пригодным для программирования вообще и для разработки библиотек
в частности. Логически схожий пример в С++ представляют манипуляторы,
которые используются для форматирования вывода в потоковом
вводе-выводе ($$10.4.2). Заметим, что третье решение не есть "верное
решение", это просто более общее решение. Разработчик должен
сбалансировать различные требования системы, чтобы найти уровень
общности и абстракции, пригодный для данной задачи в данной области.
Золотое правило: для программы с долгим сроком жизни правильным
будет самый общий уровень абстракции, который вам еще понятен и
который вы можете себе позволить, но не обязательно абсолютно
общий. Обобщение, выходящее за пределы данного проекта и
понятия людей, в нем участвующих, может принести вред, т.е.
привести к задержкам, неприемлемым характеристикам, неуправляемым
проектам и просто к провалу.
Чтобы использование указанных методов было экономично и
поддавалось управлению, проектирование и управление должно
учитывать повторное использование, о чем говорится в $$11.4.1 и
не следует совсем забывать об эффективности (см. $$11.3.7).
Рассмотрим проектирование отдельного класса. Обычно это не лучший
метод. Понятия не существуют изолированно, наоборот, понятие
определяется в связи с другими понятиями. Аналогично и класс не
существует изолированно, а определяется совместно с множеством
связанных между собой классов. Это множество часто называют
библиотекой классов или компонентом. Иногда все классы компонента
образуют единую иерархию, иногда это не так (см. $$12.3).
Множество классов компонента бывают объединены некоторым логическим
условием, иногда это - общий стиль программирования или описания,
иногда - предоставляемый сервис. Компонент является единицей
проектирования, документации, права собственности и,
часто, повторного использования.
Это не означает, что если вы используете один класс компонента, то
должны разбираться во всех и уметь применять все классы компонента или
должны подгружать к вашей программе модули всех классов компонента. В
точности наоборот, обычно стремятся обеспечить, чтобы использование
класса вело к минимуму накладных расходов: как машинных ресурсов,
так и человеческих усилий. Но для использования любого класса
компонента нужно понимать логическое условие, которое его
определяет (можно надеяться, что оно предельно ясно изложено в
документации), понимать соглашения и стиль, примененный в процессе
проектирования и описания компонента, и доступный сервис (если он
есть).
Итак, перейдем к способам проектирования компонента. Поскольку
часто это непростая задача, имеет смысл разбить ее на шаги и,
сконцентрировавшись на подзадачах, дать полное и последовательное
описание. Обычно нет единственно правильного способа разбиения.
Тем не менее, ниже приводится описание последовательности шагов,
которая пригодилась в нескольких случаях:
[1] Определить понятие / класс и установить основные связи
между ними.
[2] Уточнить определения классов, указав набор операций для
каждого.
[a] Провести классификацию операций. В частности уточнить
необходимость построения, копирования и уничтожения.
[b] Убедиться в минимальности, полноте и удобстве.
[3] Уточнить определения классов, указав их зависимость от
других классов.
[a] Наследование.
[b] Использование зависимостей.
[4] Определить интерфейсы классов.
[a] Поделить функции на общие и защищенные.
[b] Определить точный тип операций класса.
Отметим, что это шаги итеративного процесса. Обычно для получения
проекта, который можно уверенно использовать для первичной реализации
или повторной реализации, нужно несколько раз проделать
последовательность шагов. Одним из преимуществ глубокого анализа и
предложенной здесь абстракции данных оказывается относительная
легкость, с которой можно перестроить взаимоотношения классов
даже после программирования каждого класса. Хотя это никогда не
бывает просто.
Далее следует приступить к реализации классов, а затем
вернуться, чтобы оценить проект, исходя из опыта реализации.
Рассмотрим эти шаги в отдельности.
Определите понятия/классы и установите основные связи между ними.
Главное в хорошем проекте - прямо отразить какое-либо понятие
"реальности", т.е. уловить понятие из области приложения классов,
представить взаимосвязь между классами строго определенным способом,
например, с помощью наследования, и повторить эти действия на
разных уровнях абстракции. Но как мы можем уловить эти понятия?
Как на практике решить, какие нам нужны классы?
Лучше поискать ответ в самой области приложения, чем рыться
в программистском хранилище абстракций и понятий. Обратитесь к тому,
кто стал экспертом по работе в некогда сделанной системе, а также
к тому, кто стал критиком системы, пришедшей ей на смену. Запомните
выражения того и другого.
Часто говорят, что существительные играют роль классов и объектов,
используемых в программе, это действительно так. Но это только начало.
Далее, глаголы могут представлять операции над объектами или
обычные (глобальные) функции, вырабатывающие новые значения, исходя
из своих параметров, или даже классы. В качестве примера
можно рассматривать функциональные объекты, описанные в $$10.4.2.
Такие глаголы, как "повторить" или "совершить" (commit) могут быть
представлены итеративным объектом или объектом, представляющим
операцию выполнения программы в базах данных.
Даже прилагательные можно успешно
представлять с помощью классов, например, такие, как "хранимый",
"параллельный", "регистровый", "ограниченный". Это могут быть классы,
которые помогут разработчику или программисту, задав виртуальные
базовые классы, специфицировать и выбрать нужные свойства для
классов, проектируемых позднее.
Лучшее средство для поиска этих понятий / классов - грифельная
доска, а лучший метод первого уточнения - это беседа со специалистами
в области приложения или просто с друзьями. Обсуждение необходимо,
чтобы создать начальный жизнеспособный словарь терминов и понятийную
структуру. Мало кто может сделать это в одиночку. Обратитесь к [1],
чтобы узнать о методах подобных уточнений.
Не все классы соответствуют понятиям из области приложения.
Некоторые могут представлять ресурсы системы или абстракции
периода реализации (см. $$12.2.1).
Взаимоотношения, о которых мы говорим, естественно устанавливаются
в области приложения или (в случае повторных проходов по шагам
проектирования) возникают из последующей работы над структурой классов.
Они отражают наше понимание основ области приложения. Часто они
являются классификацией основных понятий. Пример такого отношения:
машина с выдвижной лестницей есть грузовик, есть пожарная машина,
есть движущееся средство.
В $$11.3.3.2 и $$11.3.3.5 предлагается некоторая точка зрения на
классы и иерархию классов, если необходимо улучшить их структуру.
Уточните определения классов, указав набор операций для каждого.
В действительности нельзя разделить процессы определения классов и
выяснения того, какие операции для них нужны. Однако, на практике
они различаются, поскольку при определении классов внимание
концентрируется на основных понятиях, не останавливаясь
на программистских вопросах их реализации, тогда как при определении
операций прежде всего сосредотачивается на том, чтобы задать полный и
удобный набор операций. Часто бывает слишком трудно совместить оба
подхода, в особенности, учитывая, что связанные классы надо
проектировать одновременно.
Возможно несколько подходов к процессу определения набора операций.
Предлагаем следующую стратегию:
[1] Рассмотрите, каким образом объект класса будет создаваться,
копироваться (если нужно) и уничтожаться.
[2] Определите минимальный набор операций, который необходим
для понятия, представленного классом.
[3] Рассмотрите операции, которые могут быть добавлены для удобства
записи, и включите только несколько действительно важных.
[4] Рассмотрите, какие операции можно считать тривиальными, т.е.
такими, для которых класс выступает в роли интерфейса для
реализации производного класса.
[5] Рассмотрите, какой общности именования и функциональности
можно достигнуть для всех классов компонента.
Очевидно, что это - стратегия минимализма. Гораздо проще добавлять
любую функцию, приносящую ощутимую пользу, и сделать все операции
виртуальными. Но, чем больше функций, тем больше вероятность, что
они не будут использоваться, наложат определенные ограничения на
реализацию и затруднят эволюцию системы. Так, функции, которые
могут непосредственно читать и писать в переменную состояния объекта
из класса, вынуждают использовать единственный способ реализации и
значительно сокращают возможности перепроектирования. Такие функции
снижают уровень абстракции от понятия до его конкретной реализации.
К тому же добавление функций добавляет работы программисту и
даже разработчику, когда он вернется к проектированию. Гораздо
легче включить в интерфейс еще одну функцию, как только
установлена потребность в ней, чем удалить ее оттуда, когда уже
она стала привычной.
Причина, по которой мы требуем явного принятия решения о
виртуальности данной функции, не оставляя его на стадию реализации,
в том, что, объявив функцию виртуальной, мы существенно повлияем
на использование ее класса и на взаимоотношения этого класса с
другими. Объекты из класса, имеющего хотя бы одну виртуальную
функцию, требуют нетривиального распределения памяти, если сравнить
их с объектами из таких языков как С или Фортран. Класс с хотя бы
одной виртуальной функцией по сути выступает в роли интерфейса
по отношению к классам, которые "еще могут быть определены", а
виртуальная функция предполагает зависимость от классов, которые
"еще могу быть определены" (см. $$12.2.3)
Отметим, что стратегия минимализма требует, пожалуй, больших
усилий со стороны разработчика.
При определении набора операций больше внимания следует уделять
тому, что надо сделать, а не тому, как это делать.
Иногда полезно классифицировать операции класса по тому,
как они работают с внутренним состоянием объектов:
- Базовые операции: конструкторы, деструкторы, операции копирования.
- Селекторы: операции, не изменяющие состояния объекта.
- Модификаторы: операции, изменяющие состояние объекта.
- Операции преобразований, т.е. операции порождающие объект
другого типа, исходя из значения (состояния) объекта, к которому
они применяются.
- Повторители: операции, которые открывают доступ к объектам класса
или используют последовательность объектов.
Это не есть разбиение на ортогональные группы операций. Например,
повторитель может быть спроектирован как селектор или модификатор.
Выделение этих групп просто предназначено помочь в процессе
проектирования интерфейса класса. Конечно, допустима и другая
классификация. Проведение такой классификации особенно полезно для
поддержания непротиворечивости между классами в рамках одного
компонента.
В языке С++ есть конструкция, помогающая заданию селекторов и
модификаторов в виде функции-члена со спецификацией const и без нее.
Кроме того, есть средства, позволяющие явно задать конструкторы,
деструкторы и функции преобразования. Операция копирования реализуется
с помощью операций присваивания и конструкторов копирования.
Уточните определение классов, указав их зависимости от других классов.
Различные виды зависимостей обсуждаются в $$12.2. Основными по
отношению к проектированию следует считать отношения наследования
и использования. Оба предполагают понимание того, что значит для
класса отвечать за определенное свойство системы. Отвечать за что-либо
не означает, что класс должен содержать в себе всю информацию, или,
что его функции-члены должны сами проводить все необходимые операции.
Как раз наоборот, каждый класс, имеющий определенный уровень
ответственности, организует работу, перепоручая ее в виде
подзадач другим классам, которые имеют меньший уровень ответственности.
Но надо предостеречь, что злоупотребление этим приемом приводит
к неэффективным и плохо понимаемым проектам, поскольку
происходит размножение классов и объектов до такой степени, что
вместо реальной работы производится только серия запросов на
ее выполнение. То, что можно сделать в данном месте, следует
сделать.
Необходимость учесть отношения наследования и использования
на этапе проектирования (а не только в процессе реализации) прямо
вытекает из того, что классы представляют определенные понятия.
Отсюда также следует, что именно компонент (т.е. множество
связанных классов), а не отдельный класс, являются единицей
проектирования.
Определите интерфейсы классов. На этой стадии проектирования не нужно
рассматривать приватные функции. Вопросы реализации, возникающие на
стадии проектирования, лучше всего обсуждать на шаге 3 при
рассмотрении различных зависимостей. Более того, существует
золотое правило: если класс не допускает по крайней мере двух
существенно отличающихся реализаций, то что-то явно не в порядке с этим
классом, это просто замаскированная реализация, а не представление
абстрактного понятия. Во многих случаях для ответа на вопрос:
"Достаточно ли интерфейс класса независим от реализации?"- надо
указать, возможна ли для класса схема ленивых вычислений.
Отметим, что общие базовые классы и друзья (friend) являются
частью общего интерфейса класса (см. $$5.4.1 и $$12.4). Полезным
упражнением может быть определение раздельного интерфейса для
классов-наследников и всех остальных классов с помощью разбиения
интерфейса на общую и закрытые части.
Именно на этом шаге следует продумать и описать точные определения
типов аргументов. В идеале желательно иметь максимальное число
интерфейсов со статическими типами, относящимися к области приложения
(см. $$12.1.3 и $$12.4).
При определении интерфейсов следует обратить внимание на те
классы, где набор операций представлен более, чем на одном уровне
абстракции. Например, в классе file у некоторых функций-членов
аргументы имеют тип file_descriptor (дескриптор_файла), а у других
аргументы - строка символов, которая обозначает имя файла.
Операции с file_descriptor работают на другом уровне (меньшем)
абстракции, чем операции с именем файла, так что даже странно,
что они относятся к одному классу. Возможно, было бы лучше иметь
два класса: один представляет понятие дескриптора файла, а
другой - понятие имени файла. Обычно все операции класса должны
представлять понятия одного уровня абстракции. Если это не так,
то стоит подумать о реорганизации и его, и связанных с ним классов.
Шаги 1 и 3 требуют исследования классов и их иерархии, чтобы
убедиться, что они адекватно отвечают нашим требованиям. Обычно
это не так, и приходится проводить перестройку для улучшения
структуры, проекта или реализации.
Самая типичная перестройка иерархии классов состоит в выделении
общей части двух классов в новый класс или в разбиении класса на два
новых. В обоих случаях в результате получится три класса:
базовый класс и два
производных. Когда следует проводить такую перестройку? Каковы
общие показания, что такая перестройка будет полезной?
К сожалению нет простого и универсального ответа на эти
вопросы. Это и не удивительно, поскольку то, что предлагается,
не является мелочью при реализации, а изменяет основные