вать неудачу. Ќужно иметь
организацию и стратегию развитиЯ программного обеспечениЯ, которые
нацелены на создание и поддержание многих версий разных систем, т.е.
нужно многократное планирование успеха.
    –ель проектированиЯ в выработке Ясной и относительно простой
внутренней структуры программы, называемой иногда архитектурой, иными
словами каркаса, в который укладываютсЯ отдельные программные фрагменты,
и который помогает написанию этих фрагментов.
   Џроект - конечный результат процесса проектированиЯ (если только
бывает конечный продукт у итеративного процесса). Ћн ЯвлЯетсЯ
средоточием взаимодействий между разработчиком и программистом и
между программистами. ‡десь необходимо соблюсти чувство меры. …сли Я,
как отдельный программист, проектирую небольшую программу, которую
собираюсь написать завтра, то точность и полнота описаниЯ проекта
может свестись к нескольким каракулЯм на обратной стороне конверта.
Ќа другом полюсе находитсЯ система, над которой работают сотни
программистов и разработчиков, и здесь могут потребоватьсЯ тома
тщательно составленных спецификаций проекта на формальном или
полуформальном Языке. Ћпределение нужной степени точности, детализации
и формальности проектированиЯ ЯвлЯетсЯ уже само по себе нетривиальной
технической и административной задачей.
   „алее будет предполагатьсЯ, что проект системы записываетсЯ
как рЯд определений классов (в которых частные описаниЯ опущены
как лишние детали) и взаимоотношений между ними. ќто упрощение, т.к.
конкретный проект может учитывать: вопросы параллельности, использование
глобального пространства имен, использование глобальных функций и
данных, построение программы длЯ минимизации перетранслЯции,
устойчивость, многомашинный режим и т.п. Ќо при обсуждении на данном
уровне детализации без упрощениЯ не обойтись, а классы в контексте ‘++
ЯвлЯютсЯ ключевым понЯтием проектированиЯ. Ќекоторые из указанных
вопросов будут обсуждатьсЯ ниже, а те, которые прЯмо затрагивают
проектирование библиотек ‘++, будут рассмотрены в главе 13. Ѓолее
подробное обсуждение и примеры определенных методов объектно-
ориентированного проектированиЯ содержатсЯ в [2].
    Њы сознательно не проводили четкого разделениЯ анализа и
проектированиЯ, поскольку обсуждение их различий выходит за рамки этой
книги, и оно зависит от применЯемых методов проектированиЯ. ѓлавное в том,
чтобы выбрать метод анализа, подходЯщий длЯ метода проектированиЯ, и
выбрать метод проектированиЯ, подходЯщий длЯ стилЯ программированиЯ
и используемого Языка.

        11.3 Џроцесс развитиЯ

Џроцесс развитиЯ программного обеспечениЯ - это итеративный и
расширЯющийсЯ процесс. Џо мере развитиЯ каждаЯ стадиЯ повторЯетсЯ
многократно, и при всЯком возврате на некоторую стадию процесса уточнЯетсЯ
конечный продукт, получаемый на этой стадии. ‚ общем случае процесс
не имеет ни начала, ни конца, поскольку, проектируЯ и реализуЯ систему,
вы начинаете, используЯ как базу другие проекты, библиотеки и прикладные
системы, в конце работы после вас остаетсЯ описание проекта и программа,
которые другие могут уточнЯть, модифицировать, расширЯть и переносить.
…стественно конкретный проект имеет определенное начало и конец, и
важно (хотЯ часто удивительно трудно) четко и строго ограничить времЯ
и область действиЯ проекта. Ќо заЯвление, что вы начинаете с "чистого
листа", может привести к серьезным проблемам длЯ вас, также как и позициЯ,
что после передачи окончательной версии - хоть потоп, вызовет
серьезные проблемы длЯ ваших последователей (или длЯ вас в новой
роли).
    €з этого вытекает, что следующие разделы можно читать в любом
порЯдке, поскольку вопросы проектированиЯ и реализации могут в
реальном проекте переплетатьсЯ почти произвольно. €менно, "проект"
почти всегда подвергаетсЯ перепроектированию на основе предыдущего
проекта, определенного опыта реализации, ограничений, накладываемых
сроками, мастерством работников, вопросами совместимости и т.п.
‡десь основнаЯ трудность длЯ менеджера или разработчика или
программиста в том, чтобы создать такой порЯдок в этом процессе,
который не препЯтствует усовершенствованиЯм и не запрещает повторные
проходы, необходимые длЯ успешного развитиЯ.
   “ процесса развитиЯ три стадии:
 - Ђнализ: определение области задачи.
 - Џроектирование: создание общей структуры системы.
 - ђеализациЯ: программирование и тестирование.
Ќе забудьте об итеративной природе этих процессов (неспроста стадии
не были пронумерованы), и заметьте, что никакие важные аспекты процесса
развитиЯ программы не выделЯютсЯ в отдельные стадии, поскольку они
должны допускать:
 - ќкспериментирование.
 - ’естирование.
 - Ђнализ проектированиЯ и реализации.
 - „окументирование.
 - ‘опровождение.
 ‘опровождение программного обеспечениЯ рассматриваетсЯ просто как
 еще несколько проходов по стадиЯм процесса развитиЯ (см. также
$$11.3.6).
   Ћчень важно, чтобы анализ, проектирование и реализациЯ не были
слишком оторваны друг от друга, и чтобы люди, принимающие в них
участие, были одного уровнЯ квалификации длЯ налаживаниЯ эффективных
контактов.
‚ больших проектах слишком часто бывает иначе. ‚ идеале, в процессе
развитиЯ проекта работники должны сами переходить с одной стадии на
другую: лучший способ передачи тонкой информации - это использовать
голову работника. Љ сожалению, в организациЯх часто устанавливают
барьеры длЯ таких переходов, например, у разработчика может быть
более высокий статус и (или) более высокий оклад, чем у "простого"
программиста. Ќе принЯто, чтобы сотрудники ходили по отделам с целью
набратьсЯ опыта и знаний, но пусть, по крайней мере, будут
регулЯрными собеседованиЯ сотрудников, занЯтых на разных стадиЯх проекта.
   „лЯ средних и малых проектов обычно не делают различиЯ между
анализом и проектированием - эти стадии сливаютсЯ в одну. „лЯ малых
проектов также не разделЯют проектирование и программирование.
Љонечно, тем самым решаетсЯ проблема взаимодействиЯ. „лЯ данного
проекта важно найти подходЯщую степень формализации и выдержать
нужную степень разделениЯ между стадиЯми ($$11.4.2). Ќет единственно
верного способа длЯ этого.
   ЏриведеннаЯ здесь модель процесса развитиЯ программного обеспечениЯ
радикально отличаетсЯ от традиционной модели "каскад" (waterfall).
‚ последней процесс развитиЯ протекает линейно от стадии анализа до
стадии тестированиЯ. Ћсновной недостаток модели каскад тот, что в ней
информациЯ движетсЯ только в одном направлении. …сли выЯвлена
проблема "ниже по течению", то возникает сильное методологическое
и организационное давление, чтобы решить проблему на данном уровне,
не затрагиваЯ предыдущих стадий процесса. Ћтсутствие повторных
проходов приводит к дефектному проекту, а в результате локального
устранениЯ проблем получаетсЯ искаженнаЯ реализациЯ. ‚ тех
неизбежных случаЯх, когда информациЯ должна быть передана назад к
источнику ее получениЯ и вызвать изменениЯ в проекте, мы получим
лишь слабое "колыхание" на всех уровнЯх системы, стремЯщейсЯ подавить
внесенное изменение, а значит система плохо приспособлена к
изменениЯм. Ђргумент в пользу "никаких изменений" или "только локальные
изменениЯ" часто сводитсЯ к тому, что один отдел не хочет
перекладывать большую работу на другой отдел "ради их же блага".
—асто бывает так, что ко времени, когда ошибка уже найдена, исписано
столько бумаги относительно ошибочного решениЯ, что усилиЯ,
нужные на исправление документации, затмевают усилиЯ длЯ исправлениЯ
самой программы. ’аким образом, бумажнаЯ работа может стать главной
проблемой процесса созданиЯ системы. Љонечно, такие проблемы могут быть
и возникают в процессе развитиЯ больших систем. ‚ конце концов,
определеннаЯ работа с бумагами необходима. Ќо выбор линейной модели
развитиЯ (каскад) многократно увеличивает вероЯтность, что эта
проблема выйдет из-под контролЯ.
Ќедостаток модели каскад в отсутствии повторных проходов и
неспособности реагировать на изменениЯ. Ћпасность предлагаемой здесь
итеративной модели состоит в искушении заменить размышление и
реальное развитие на последовательность бесконечных изменений.
’от и другой недостатки легче указать, чем устранить, и длЯ того,
кто организует работу, легко принЯть простую активность за реальный
прогресс.
    ‚ы можете уделЯть пристальное внимание деталЯм, использовать
разумные приемы управлениЯ, развитую технологию, но ничто не спасет
вас, если нет Ясного пониманиЯ того, что вы пытаетесь создать. Ѓольше
всего проектов проваливалось именно из-за отсутствиЯ хорошо
сформулированных реалистичных целей, а не по какой-либо иной причине.
—то бы вы не делали и чем бы не занимались, надо Ясно представлЯть
имеющиесЯ у вас средства, ставить достижимые цели и ориентиры и не
искать технических решений социологических проблем. ‘ другой стороны,
надо применЯть только адекватную технологию, даже если она потребует
затрат,- люди работают лучше, имеЯ адекватные средства и приемлемую
среду. Ќе заблуждайтесь, думаЯ, что легко выполнить эти рекомендации.

        11.3.1 –икл развитиЯ

Џроцесс развитиЯ системы - это итеративнаЯ деЯтельность. Ћсновной
цикл сводитсЯ к повторЯемым в следующей последовательности шагам:
 [1] ‘оздать общее описание проекта.
 [2] ‚ыделить стандартные компоненты.
     [a] Џодогнать компоненты под данный проект.
 [3] ‘оздать новые стандартные компоненты.
     [a] Џодогнать компоненты под данный проект.
 [4] ‘оставить уточненное описание проекта.
‚ качестве примера рассмотрим автомобильный завод. Џроект должен
начинатьсЯ с самого общего описаниЯ новой машины. ќтот первый шаг
базируетсЯ на некотором анализе и описании машины в самых общих
терминах, которые скорее относЯтсЯ к предполагаемому использованию,
чем к характеристикам желаемых возможностей машины. —асто самой
трудной частью проекта бывает выбор желаемых возможностей, или,
точнее, определение относительно простого критериЯ выбора желаемых
возможностей. “дача здесь, как правило, ЯвлЯетсЯ
результатом работы отдельного проницательного человека и часто
называетсЯ предвидением. ‘лишком типично как раз отсутствие
Ясных целей, что приводит к неуверенно развивающимсЯ или просто
проваливающимсЯ проектам.
    €так, допустим необходимо создать машину среднего размера с
четырьмЯ дверцами и достаточно мощным мотором. Ћчевидно, что
на первом этапе проекта не следует начинать проектирование машины
(и всех ее компонентов) с нулЯ. •отЯ программист или разработчик
программного обеспечениЯ в подобных обстоЯтельствах поступит именно
так.
     Ќа первом этапе надо выЯснить, какие компоненты доступны на
вашем собственном складе и какие можно получить от надежных
поставщиков. Ќайденные таким образом компоненты не обЯзательно
в точности подойдут длЯ новой машины. ‚сегда требуетсЯ подгонка
компонентов. Њожет быть даже потребуетсЯ изменить характеристики
"следующей версии" выбранных компонентов, чтобы сделать их
пригодными длЯ проекта. Ќапример, может существовать вполне пригодный
мотор, вырабатывающий немного меньшую мощность.’огда
или вы, или поставщик мотора должны предложить, не изменЯЯ общего
описаниЯ проекта, в качестве компенсации дополнительный
зарЯдный генератор.  ‡аметим, что сделать это,"не изменЯЯ общего описаниЯ
проекта", маловероЯтно, если только само описание не приспособлено
к определенной подгонке. Ћбычно подобнаЯ
подгонка требует кооперации между вами и поставщиком моторов.
‘ходные вопросы возникают и у программиста или разработчика
программного обеспечениЯ. ‡десь подгонку обычно облегчает эффективное
использование производных классов. Ќо не рассчитывайте провести
произвольные расширениЯ в проекте без определенного предвидениЯ
или кооперации с создателем таких классов.
    Љогда исчерпаетсЯ набор подходЯщих стандартных компонентов,
проектировщик машины не спешит занЯтьсЯ проектированием новых
оптимальных компонентов длЯ своей машины. ќто было бы слишком
расточительно. „опустим, что не нашлось подходЯщего блока
кондиционированиЯ воздуха, зато есть свободное пространство, имеющее
форму буквы L, в моторном отсеке. ‚озможно решение разработать
блок кондиционированиЯ указанной формы. Ќо вероЯтность того, что
блок подобной странной формы будет использоватьсЯ в машинах другого
типа (даже после значительной подгонки), крайне низка. ќто означает,
что наш проектировщик машины не сможет разделить затраты на
производство такого блока с создателЯми машин другого типа, а значит
времЯ жизни этого блока коротко. Џоэтому стоит спроектировать блок,
который найдет более широкое применение, т.е. разработать
разумный проект блока, более приспособленный длЯ подгонки, чем наше
L-образное чудище. ‚озможно, это потребует больших усилий, и даже
придетсЯ длЯ приспособлениЯ более универсального блока изменить
общее описание проекта машины. Џоскольку новый блок разрабатывалсЯ
длЯ более общего применениЯ, чем наше L-образное чудище,
предположительно, длЯ него потребуетсЯ некотораЯ подгонка, чтобы
полностью удовлетворить наши пересмотренные запросы.
ЏодобнаЯ же альтернатива возникает и у программиста или разработчика
программного обеспечениЯ: вместо того, чтобы создать программу,
привЯзанную к конкретному проекту, разработчик может спроектировать
новую достаточно универсальную программу, котораЯ будет иметь
хорошие шансы стать стандартной в определенной области.
     Ќаконец, когда мы прошлись по всем стандартным компонентам,
составлЯетсЯ "окончательное" общее описание проекта. Ќесколько
специально разработанных средств указываютсЯ как возможные. ‚ероЯтно,
в следующем году придетсЯ длЯ новой модели повторить наши шаги,
и как раз эти специальные средства придетсЯ переделать или выбросить.
Љак ни печально, но опыт традиционно проектировавшихсЯ программ
показывает, что лишь несколько частей системы можно выделить в
отдельные компоненты и лишь несколько из них пригодны вне
данного проекта.
     Њы не пытаемсЯ утверждать, что все разработчики машин
действуют столь разумно, как в приведенном примере, а разработчики
программ совершают все указанные ошибки. “тверждаетсЯ, что указаннаЯ
методика разработки машин применима и длЯ программного обеспечениЯ.
’ак, в этой и следующей главах даны приемы использованиЯ ее длЯ ‘++.
’ем не менее можно сказать, что сама природа программированиЯ
способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5).
‚ разделе 11.4.3 опровергаетсЯ профессиональное предубеждение против
использованиЯ описанной здесь модели проектированиЯ.
 ‡аметим, что модель развитиЯ программного обеспечениЯ хорошо
применима только в расчете на большие сроки. …сли ваш горизонт
сужаетсЯ до времени выдачи очередной версии, нет смысла создавать
и поддерживать функционирование стандартных компонентов. ќто
просто приведет к излишним накладным расходам. Ќаша модель
рассчитана на организации со временем жизни, за которое проходит
несколько проектов, и с размерами, которые позволЯют нести
дополнительные расходы и на средства проектированиЯ, программированиЯ,
и на сопровождение проектов, и на повышение квалификации разработчиков,
программистов и менеджеров. ”актически это эскиз некоторой фабрики по
производству программ. Љак ни удивительно, она только масштабом
отличаетсЯ от действий лучших программистов, которые длЯ повышениЯ своей
производительности в течении лет накапливали запас приемов и методов
проектированиЯ, создавали инструменты и библиотеки. Џохоже, что
большинство организаций просто не умеет воспользоватьсЯ достижениЯми
лучших сотрудников, как из-за отсутствиЯ предвидениЯ, так и по
неспособности применить эти достижениЯ в достаточно широком
объеме.
    ‚се-таки неразумно требовать, чтобы "стандартные компоненты"
были стандартными универсально. ‘уществует лишь малое число
международных стандартных библиотек, а в своем большинстве компоненты
окажутсЯ стандартными только в пределах страны, отрасли, компании,
производственной цепочки, отдела или области приложениЯ и т.д.
Џросто мир слишком велик, чтобы универсальный стандарт
всех компонентов и средств был реальной или желанной целью проекта.


        11.3.2 –ели проектированиЯ

Љаковы самые общие цели проектированиЯ? Љонечно, простота, но в чем
критерий простоты? Џоскольку мы считаем, что проект должен развиватьсЯ
во времени, т.е. система будет расширЯтьсЯ, переноситьсЯ,
настраиватьсЯ и, вообще, изменЯтьсЯ массой способов, которые невозможно
предусмотреть, необходимо стремитьсЯ к такой системе проектированиЯ
и реализации, котораЯ была бы простой с учетом, что она будет
менЯтьсЯ многими способами. Ќа самом деле, практично допустить,
что сами требованиЯ к системе будут менЯтьсЯ неоднократно за период
от начального проекта до выдачи первой версии системы.
     ‚ывод таков: система должна проектироватьсЯ максимально простой
при условии, что она будет подвергатьсЯ серии изменений. Њы должны
проектировать в расчете на изменениЯ, т.е. стремитьсЯ к
  - гибкости,
  - расширЯемости и
  - переносимости
‹учшее решение - выделить части системы, которые вероЯтнее всего будут
менЯтьсЯ, в самостоЯтельные единицы, и предоставить программисту или
разработчику гибкие возможности длЯ модификаций таких единиц. ќто
можно сделать, если выделить ключевые длЯ данной задачи понЯтиЯ
и предоставить класс, отвечающий за всю информацию, свЯзанную с
отдельным понЯтием (и только с ним). ’огда изменение будет затрагивать
только определенный класс. …стественно, такой идеальный способ
гораздо легче описать, чем воплотить.
   ђассмотрим пример: в задаче моделированиЯ метеорологических
объектов нужно представить дождевое облако. Љак это сделать?
“ нас нет общего метода изображениЯ облака, поскольку его вид зависит
от внутреннего состоЯниЯ облака, а оно может быть задано только
самим облаком.
    Џервое решение: пусть облако изображает себЯ само. Ћно подходит
длЯ многих ограниченных приложений. Ќо оно не ЯвлЯетсЯ достаточно
общим, поскольку существует много способов представлениЯ облака:
детальнаЯ картина, набросок очертаний, пиктограмма, карта и т.п.
„ругими словами, вид облака определЯетсЯ как им самим, так и его
окружением.
    ‚торое решение заключаетсЯ в том, чтобы предоставить самому облаку
длЯ его изображениЯ сведениЯ о его окружении. Ћно годитсЯ длЯ
большего числа случаев. Ћднако и это не общее решение. …сли мы
предоставлЯем облаку сведениЯ об его окружении, то нарушаем основной
постулат, который требует, чтобы класс отвечал только за одно
понЯтие, и каждое понЯтие воплощалось определенным классом.
Њожет оказатьсЯ невозможным предложить согласованное определение
"окружениЯ облака", поскольку, вообще говорЯ, как выглЯдит облако
зависит от самого облака и наблюдателЯ. —ем представлЯетсЯ облако
мне, сильно зависит от того, как Я смотрю на него: невооруженным
глазом, с помощью полЯризационного фильтра, с помощью метеорадара и т.д.
Џомимо наблюдателЯ и облака следует учитывать и "общий фон", например,
относительное положение солнца. Љ дальнейшему усложнению картины
приводит добавление новых объектов типа других облаков, самолетов.
—тобы сделать задачу разработчика практически неразрешимой, можно
добавить возможность одновременного существованиЯ нескольких
наблюдателей.
     ’ретье решение состоит в том, чтобы облако, а также и другие
объекты, например, самолеты или солнце, сами описывали себЯ по
отношению к наблюдателю. ’акой подход обладает достаточной
общностью, чтобы удовлетворить большинство запросовњ. Ћднако,
он может привести к значительному усложнению и большим накладным
расходам при выполнении. Љак, например, добитьсЯ того, чтобы
наблюдатель понимал описаниЯ, произведенные облаком или другими
объектами?

њ „аже эта модель будет, по всей видимости, не достаточной длЯ таких
  предельных случаев, как графика с высокой степенью разрешимости.
  џ думаю, что длЯ получениЯ очень детальной картины нужен другой
  уровень абстракции.

     „ождевые облака - это не тот объект, который часто встретишь
в программах, но объекты, участвующие в различных операциЯх ввода
и вывода, встречаютсЯ часто. Џоэтому можно считать пример с облаком
пригодным длЯ программированиЯ вообще и длЯ разработки библиотек
в частности. ‹огически схожий пример в ‘++ представлЯют манипулЯторы,
которые используютсЯ длЯ форматированиЯ вывода в потоковом
вводе-выводе ($$10.4.2). ‡аметим, что третье решение не есть "верное
решение", это просто более общее решение. ђазработчик должен
сбалансировать различные требованиЯ системы, чтобы найти уровень
общности и абстракции, пригодный длЯ данной задачи в данной области.
‡олотое правило: длЯ программы с долгим сроком жизни правильным
будет самый общий уровень абстракции, который вам еще понЯтен и
который вы можете себе позволить, но не обЯзательно абсолютно
общий. Ћбобщение, выходЯщее за пределы данного проекта и
понЯтиЯ людей, в нем участвующих, может принести вред, т.е.
привести к задержкам, неприемлемым характеристикам, неуправлЯемым
проектам и просто к провалу.
     —тобы использование указанных методов было экономично и
поддавалось управлению, проектирование и управление должно
учитывать повторное использование, о чем говоритсЯ в $$11.4.1 и
не следует совсем забывать об эффективности (см. $$11.3.7).

        11.3.3 аги проектированиЯ

ђассмотрим проектирование отдельного класса. Ћбычно это не лучший
метод. ЏонЯтиЯ не существуют изолированно, наоборот, понЯтие
определЯетсЯ в свЯзи с другими понЯтиЯми. Ђналогично и класс не
существует изолированно, а определЯетсЯ совместно с множеством
свЯзанных между собой классов. ќто множество часто называют
библиотекой классов или компонентом. €ногда все классы компонента
образуют единую иерархию, иногда это не так (см. $$12.3).
   Њножество классов компонента бывают объединены некоторым логическим
условием, иногда это - общий стиль программированиЯ или описаниЯ,
иногда - предоставлЯемый сервис. Љомпонент ЯвлЯетсЯ единицей
проектированиЯ, документации, права собственности и,
часто, повторного использованиЯ.
ќто не означает, что если вы используете один класс компонента, то
должны разбиратьсЯ во всех и уметь применЯть все классы компонента или
должны подгружать к вашей программе модули всех классов компонента. ‚
точности наоборот, обычно стремЯтсЯ обеспечить, чтобы использование
класса вело к минимуму накладных расходов: как машинных ресурсов,
так и человеческих усилий. Ќо длЯ использованиЯ любого класса
компонента нужно понимать логическое условие, которое его
определЯет (можно надеЯтьсЯ, что оно предельно Ясно изложено в
документации), понимать соглашениЯ и стиль, примененный в процессе
проектированиЯ и описаниЯ компонента, и доступный сервис (если он
есть).
     €так, перейдем к способам проектированиЯ компонента. Џоскольку
часто это непростаЯ задача, имеет смысл разбить ее на шаги и,
сконцентрировавшись на подзадачах, дать полное и последовательное
описание. Ћбычно нет единственно правильного способа разбиениЯ.
’ем не менее, ниже приводитсЯ описание последовательности шагов,
котораЯ пригодилась в нескольких случаЯх:
  [1] Ћпределить понЯтие / класс и установить основные свЯзи
      между ними.
  [2] “точнить определениЯ классов, указав набор операций длЯ
      каждого.
      [a] Џровести классификацию операций. ‚ частности уточнить
          необходимость построениЯ, копированиЯ и уничтожениЯ.
      [b] “бедитьсЯ в минимальности, полноте и удобстве.
  [3] “точнить определениЯ классов, указав их зависимость от
      других классов.
      [a] Ќаследование.
      [b] €спользование зависимостей.
  [4] Ћпределить интерфейсы классов.
      [a] Џоделить функции на общие и защищенные.
      [b] Ћпределить точный тип операций класса.
Ћтметим, что это шаги итеративного процесса. Ћбычно длЯ получениЯ
проекта, который можно уверенно использовать длЯ первичной реализации
или повторной реализации, нужно несколько раз проделать
последовательность шагов. Ћдним из преимуществ глубокого анализа и
предложенной здесь  абстракции  данных  оказываетсЯ относительнаЯ
легкость, с которой можно перестроить взаимоотношениЯ классов
даже после программированиЯ каждого класса. •отЯ это никогда не
бывает просто.
     „алее следует приступить к реализации классов, а затем
вернутьсЯ, чтобы оценить проект, исходЯ из опыта реализации.
ђассмотрим эти шаги в отдельности.

        11.3.3.1 аг 1: определение классов

Ћпределите понЯтиЯ/классы и установите основные свЯзи между ними.
ѓлавное в хорошем проекте - прЯмо отразить какое-либо понЯтие
"реальности", т.е. уловить понЯтие из области приложениЯ классов,
представить взаимосвЯзь между классами строго определенным способом,
например, с помощью наследованиЯ, и повторить эти действиЯ на
разных уровнЯх абстракции. Ќо как мы можем уловить эти понЯтиЯ?
Љак на практике решить, какие нам нужны классы?
     ‹учше поискать ответ в самой области приложениЯ, чем рытьсЯ
в программистском хранилище абстракций и понЯтий. Ћбратитесь к тому,
кто стал экспертом по работе в некогда сделанной системе, а также
к тому, кто стал критиком системы, пришедшей ей на смену. ‡апомните
выражениЯ того и другого.
    —асто говорЯт, что существительные играют роль классов и объектов,
используемых в программе, это действительно так. Ќо это только начало.
„алее, глаголы могут представлЯть операции над объектами или
обычные (глобальные) функции, вырабатывающие новые значениЯ, исходЯ
из своих параметров, или даже классы. ‚ качестве примера
можно рассматривать функциональные объекты, описанные в $$10.4.2.
’акие глаголы, как "повторить" или "совершить" (commit) могут быть
представлены итеративным объектом или объектом, представлЯющим
операцию выполнениЯ программы в базах данных.
„аже прилагательные можно успешно
представлЯть с помощью классов, например, такие, как "хранимый",
"параллельный", "регистровый", "ограниченный". ќто могут быть классы,
которые помогут разработчику или программисту, задав виртуальные
базовые классы, специфицировать и выбрать нужные свойства длЯ
классов, проектируемых позднее.
     ‹учшее средство длЯ поиска этих понЯтий / классов - грифельнаЯ
доска, а лучший метод первого уточнениЯ - это беседа со специалистами
в области приложениЯ или просто с друзьЯми. Ћбсуждение необходимо,
чтобы создать начальный жизнеспособный словарь терминов и понЯтийную
структуру. Њало кто может сделать это в одиночку. Ћбратитесь к [1],
чтобы узнать о методах подобных уточнений.
     Ќе все классы соответствуют понЯтиЯм из области приложениЯ.
Ќекоторые могут представлЯть ресурсы системы или абстракции
периода реализации (см. $$12.2.1).
     ‚заимоотношениЯ, о которых мы говорим, естественно устанавливаютсЯ
в области приложениЯ или (в случае повторных проходов по шагам
проектированиЯ) возникают из последующей работы над структурой классов.
Ћни отражают наше понимание основ области приложениЯ. —асто они
ЯвлЯютсЯ классификацией основных понЯтий. Џример такого отношениЯ:
машина с выдвижной лестницей есть грузовик, есть пожарнаЯ машина,
есть движущеесЯ средство.
‚ $$11.3.3.2 и $$11.3.3.5 предлагаетсЯ некотораЯ точка зрениЯ на
классы и иерархию классов, если необходимо улучшить их структуру.

        11.3.3.2 аг 2: определение набора операций

“точните определениЯ классов, указав набор операций длЯ каждого.
‚ действительности нельзЯ разделить процессы определениЯ классов и
выЯснениЯ того, какие операции длЯ них нужны. Ћднако, на практике
они различаютсЯ, поскольку при определении классов внимание
концентрируетсЯ на основных понЯтиЯх, не останавливаЯсь
на программистских вопросах их реализации, тогда как при определении
операций прежде всего сосредотачиваетсЯ на том, чтобы задать полный и
удобный набор операций. —асто бывает слишком трудно совместить оба
подхода, в особенности, учитываЯ, что свЯзанные классы надо
проектировать одновременно.
   ‚озможно несколько подходов к процессу определениЯ набора операций.
Џредлагаем следующую стратегию:
   [1] ђассмотрите, каким образом объект класса будет создаватьсЯ,
       копироватьсЯ (если нужно) и уничтожатьсЯ.
   [2] Ћпределите минимальный набор операций, который необходим
       длЯ понЯтиЯ, представленного классом.
   [3] ђассмотрите операции, которые могут быть добавлены длЯ удобства
       записи, и включите только несколько действительно важных.
   [4] ђассмотрите, какие операции можно считать тривиальными, т.е.
       такими, длЯ которых класс выступает в роли интерфейса длЯ
       реализации производного класса.
   [5] ђассмотрите, какой общности именованиЯ и функциональности
       можно достигнуть длЯ всех классов компонента.
Ћчевидно, что это - стратегиЯ минимализма. ѓораздо проще добавлЯть
любую функцию, приносЯщую ощутимую пользу, и сделать все операции
виртуальными. Ќо, чем больше функций, тем больше вероЯтность, что
они не будут использоватьсЯ, наложат определенные ограничениЯ на
реализацию и затруднЯт эволюцию системы. ’ак, функции, которые
могут непосредственно читать и писать в переменную состоЯниЯ объекта
из класса, вынуждают использовать единственный способ реализации и
значительно сокращают возможности перепроектированиЯ. ’акие функции
снижают уровень абстракции от понЯтиЯ до его конкретной реализации.
Љ тому же добавление функций добавлЯет работы программисту и
даже разработчику, когда он вернетсЯ к проектированию. ѓораздо
легче включить в интерфейс еще одну функцию, как только
установлена потребность в ней, чем удалить ее оттуда, когда уже
она стала привычной.
      Џричина, по которой мы требуем Явного принЯтиЯ решениЯ о
виртуальности данной функции, не оставлЯЯ его на стадию реализации,
в том, что, объЯвив функцию виртуальной, мы существенно повлиЯем
на использование ее класса и на взаимоотношениЯ этого класса с
другими. Ћбъекты из класса, имеющего хотЯ бы одну виртуальную
функцию, требуют нетривиального распределениЯ памЯти, если сравнить
их с объектами из таких Языков как ‘ или ”ортран. Љласс с хотЯ бы
одной виртуальной функцией по сути выступает в роли интерфейса
по отношению к классам, которые "еще могут быть определены", а
виртуальнаЯ функциЯ предполагает зависимость от классов, которые
"еще могу быть определены" (см. $$12.2.3)
     Ћтметим, что стратегиЯ минимализма требует, пожалуй, больших
усилий со стороны разработчика.
     Џри определении набора операций больше вниманиЯ следует уделЯть
тому, что надо сделать, а не тому, как это делать.
     €ногда полезно классифицировать операции класса по тому,
как они работают с внутренним состоЯнием объектов:
  - Ѓазовые операции: конструкторы, деструкторы, операции копированиЯ.
  - ‘електоры: операции, не изменЯющие состоЯниЯ объекта.
  - Њодификаторы: операции, изменЯющие состоЯние объекта.
  - Ћперации преобразований, т.е. операции порождающие объект
    другого типа, исходЯ из значениЯ (состоЯниЯ) объекта, к которому
    они применЯютсЯ.
  - Џовторители: операции, которые открывают доступ к объектам класса
    или используют последовательность объектов.
ќто не есть разбиение на ортогональные группы операций. Ќапример,
повторитель может быть спроектирован как селектор или модификатор.
‚ыделение этих групп просто предназначено помочь в процессе
проектированиЯ интерфейса класса. Љонечно, допустима и другаЯ
классификациЯ. Џроведение такой классификации особенно полезно длЯ
поддержаниЯ непротиворечивости между классами в рамках одного
компонента.
    ‚ Языке ‘++ есть конструкциЯ, помогающаЯ заданию селекторов и
модификаторов в виде функции-члена со спецификацией const и без нее.
Љроме того, есть средства, позволЯющие Явно задать конструкторы,
деструкторы и функции преобразованиЯ. ЋперациЯ копированиЯ реализуетсЯ
с помощью операций присваиваниЯ и конструкторов копированиЯ.

        11.3.3.3 аг 3: указание зависимостей

“точните определение классов, указав их зависимости от других классов.
ђазличные виды зависимостей обсуждаютсЯ в $$12.2. Ћсновными по
отношению к проектированию следует считать отношениЯ наследованиЯ
и использованиЯ. Ћба предполагают понимание того, что значит длЯ
класса отвечать за определенное свойство системы. Ћтвечать за что-либо
не означает, что класс должен содержать в себе всю информацию, или,
что его функции-члены должны сами проводить все необходимые операции.
Љак раз наоборот, каждый класс, имеющий определенный уровень
ответственности, организует работу, перепоручаЯ ее в виде
подзадач другим классам, которые имеют меньший уровень ответственности.
Ќо надо предостеречь, что злоупотребление этим приемом приводит
к неэффективным и плохо понимаемым проектам, поскольку
происходит размножение классов и объектов до такой степени, что
вместо реальной работы производитсЯ только сериЯ запросов на
ее выполнение. ’о, что можно сделать в данном месте, следует
сделать.
     Ќеобходимость учесть отношениЯ наследованиЯ и использованиЯ
на этапе проектированиЯ (а не только в процессе реализации) прЯмо
вытекает из того, что классы представлЯют определенные понЯтиЯ.
Ћтсюда также следует, что именно компонент (т.е. множество
свЯзанных классов), а не отдельный класс, ЯвлЯютсЯ единицей
проектированиЯ.

        11.3.3.4 аг 4: определение интерфейсов

Ћпределите интерфейсы классов. Ќа этой стадии проектированиЯ не нужно
рассматривать приватные функции. ‚опросы реализации, возникающие на
стадии проектированиЯ, лучше всего обсуждать на шаге 3 при
рассмотрении различных зависимостей. Ѓолее того, существует
золотое правило: если класс не допускает по крайней мере двух
существенно отличающихсЯ реализаций, то что-то Явно не в порЯдке с этим
классом, это просто замаскированнаЯ реализациЯ, а не представление
абстрактного понЯтиЯ. ‚о многих случаЯх длЯ ответа на вопрос:
"„остаточно ли интерфейс класса независим от реализации?"- надо
указать, возможна ли длЯ класса схема ленивых вычислений.
   Ћтметим, что общие базовые классы и друзьЯ (friend) ЯвлЯютсЯ
частью общего интерфейса класса (см. $$5.4.1 и $$12.4). Џолезным
упражнением может быть определение раздельного интерфейса длЯ
классов-наследников и всех остальных классов с помощью разбиениЯ
интерфейса на общую и закрытые части.
   €менно на этом шаге следует продумать и описать точные определениЯ
типов аргументов. ‚ идеале желательно иметь максимальное число
интерфейсов со статическими типами, относЯщимисЯ к области приложениЯ
(см. $$12.1.3 и $$12.4).
    Џри определении интерфейсов следует обратить внимание на те
классы, где набор операций представлен более, чем на одном уровне
абстракции. Ќапример, в классе file у некоторых функций-членов
аргументы имеют тип file_descriptor (дескриптор_файла), а у других
аргументы - строка символов, котораЯ обозначает имЯ файла.
Ћперации с file_descriptor работают на другом уровне (меньшем)
абстракции, чем операции с именем файла, так что даже странно,
что они относЯтсЯ к одному классу. ‚озможно, было бы лучше иметь
два класса: один представлЯет понЯтие дескриптора файла, а
другой - понЯтие имени файла. Ћбычно все операции класса должны
представлЯть понЯтиЯ одного уровнЯ абстракции. …сли это не так,
то стоит подумать о реорганизации и его, и свЯзанных с ним классов.

        11.3.3.5 Џерестройка иерархии классов

 аги 1 и 3 требуют исследованиЯ классов и их иерархии, чтобы
убедитьсЯ, что они адекватно отвечают нашим требованиЯм. Ћбычно
это не так, и приходитсЯ проводить перестройку длЯ улучшениЯ
структуры, проекта или реализации.
     ‘амаЯ типичнаЯ перестройка иерархии классов состоит в выделении
общей части двух классов в новый класс или в разбиении класса на два
новых. ‚ обоих случаЯх в результате получитсЯ три класса:
базовый класс и два
производных. Љогда следует проводить такую перестройку? Љаковы
общие показаниЯ, что такаЯ перестройка будет полезной?
     Љ сожалению нет простого и универсального ответа на эти
вопросы. ќто и не удивительно, поскольку то, что предлагаетсЯ,
не ЯвлЯетсЯ мелочью при реализации, а изменЯет основные
понЯтиЯ системы. ‚ажной и нетривиальной задачей ЯвлЯетсЯ поиск
общности среди классов и выделение общей части.  Ќет точного
определениЯ общности, но следует обращать внимание на общность
длЯ понЯтий системы, а не просто длЯ удобства реализации. “казаниЯми,
что два класса имеют нечто общее, что возможно выделить в общий базовый
класс, служат схожие способы использованиЯ, сходство наборов операций,
сходство реализаций и просто тот факт, что часто в процессе обсуждениЯ
проекта оба   класса   поЯвлЯютсЯ  одновременно.  ‘ другой
стороны,  если  есть
несколько наборов операций класса с различными способами использованиЯ,
если эти наборы обеспечивают доступ к раздельным подмножествам объектов
реализации, и, если класс возникает в процессе обсуждениЯ несвЯзанных
тем, то этот класс ЯвлЯетсЯ Явным кандидатом длЯ разбиениЯ на части.
       ‚ силу тесной свЯзи между понЯтиЯми и классами проблемы
перестройки иерархии классов высвечиваютсЯ на поверхности проблем
именованиЯ классов и использованиЯ имен классов в процессе обсуждениЯ
проекта. …сли имена классов и их упорЯдоченность, задаваемаЯ иерархией
классов, кажутсЯ неудобными при обсуждении проекта, значит, по всей
видимости, есть возможность улучшениЯ иерархии. ‡аметим, что
подразумеваетсЯ, что анализ иерархии классов лучше проводить не в
одиночку. …сли вы оказались в таком положении, когда не с кем
обсудить проект, хорошим выходом будет попытатьсЯ составить учебное
описание системы, используЯ имена классов.

        11.3.3.6 €спользование моделей

Љогда пишешь статью, пытаешьсЯ найти подходЯщую длЯ темы модель. Ќужно
не бросатьсЯ сразу печатать текст, а поискать статьи на сходные темы,
вдруг найдетсЯ такаЯ, котораЯ может послужить отправной точкой.
…сли ею окажетсЯ моЯ собственнаЯ статьЯ, то можно будет использовать
даже куски из нее, изменЯЯ по мере надобности другие части, и вводить
новую информацию только там, где требует логика предмета. ’аким
образом, исходЯ из первого изданиЯ, написана эта книга. Џредельный
случай такого подхода - это написание открытки-формулЯра, где просто
нужно указать имЯ и, возможно, добавить пару строк длЯ приданиЯ
"личного" отношениЯ. Џо сути такие открытки пишутсЯ с указанием отличиЯ
от стандарта.
     ‚о всех видах творческой деЯтельности использование существующих
систем в качестве моделей длЯ новых проектов ЯвлЯетсЯ скорее правилом,
а не исключением. ‚сегда, когда это возможно, проектирование и
программирование должны основыватьсЯ на предыдущих работах. ќто
сокращает степени свободы длЯ разработчика и позволЯет сосредоточить
внимание на меньшем числе вопросов в заданное времЯ. Ќачать большой
проект "практически с нулЯ" - это может возбуждать, но правильнее будет
употребить термин "опьЯнение", которое приведет к "пьЯному
блужданию" в множестве вариантов. Џостроение модели не накладывает
каких-либо ограничений и не означает покорного следованиЯ ей, это
просто освобождает разработчика от некоторых вопросов.
     ‡аметим, что на самом деле использование моделей неизбежно,
поскольку каждый проект синтезируетсЯ из опыта его разработчиков.
‹учше, когда использование модели ЯвлЯетсЯ Явно сформулированным
решением, тогда все допущениЯ делаютсЯ Явно, определЯетсЯ общий
словарь терминов, поЯвлЯетсЯ начальный каркас проекта и увеличиваетсЯ
вероЯтность того, что у разработчиков есть общий подход.
      …стественно, что выбор начальной модели ЯвлЯетсЯ важным решением,
и обычно оно принимаетсЯ только после поиска потенциальных моделей
и тщательной оценки вариантов. Ѓолее того, во многих случаЯх модель
подходит только при условии пониманиЯ того, что потребуютсЯ
значительные изменениЯ длЯ воплощениЯ ее идей в иной области
приложениЯ. Ќо проектирование программного обеспечениЯ - тЯжелый
труд, и надо использовать любую помощь. Ќе следует отказыватьсЯ
от использованиЯ моделей из-за неоправданного пренебрежениЯ к
имитации. €митациЯ - не что иное, как форма искреннего восхищениЯ,
а, с учетом права собственности и авторского права, использование
моделей и предшествующих работ в качестве источника вдохновениЯ -
допустимый способ длЯ всех новаторских работ во всех видах
деЯтельности. ’о, что было позволено експиру, подходит и длЯ нас.
Ќекоторые обозначают использование моделей в процессе проектированиЯ
как "проектирование повторного использованиЯ".

        11.3.4 ќксперимент и анализ

‚ начале честолюбивого проекта нам неизвестен лучший способ построениЯ
системы. —асто бывает так, что мы даже не знаем точно, что должна
делать система, поскольку конкретные факты проЯснЯтсЯ только в процессе
построениЯ, тестированиЯ и эксплуатации системы. Љак задолго до
созданиЯ законченной системы получить сведениЯ, необходимые длЯ
пониманиЯ того, какие решениЯ при проектировании окажутсЯ
существенными, и к каким последствиЯм они приведут?
     Ќужно проводить эксперименты. Љонечно, нужен анализ проекта и его
реализации, как только поЯвлЯетсЯ пища длЯ него. Џреимущественно
обсуждение вертитсЯ вокруг альтернатив при проектировании и
реализации. ‡а исключением редких случаев проектирование есть
социальнаЯ активность, котораЯ ведет по пути презентации и
обсуждений. —асто самым важным средством проектированиЯ оказываетсЯ
простаЯ грифельнаЯ доска; без нее идеи проекта, находЯщиесЯ в
зародыше, не могут развитьсЯ и стать общим достоЯнием в среде
разработчиков и программистов.
     Џохоже, что самый популЯрный способ проведениЯ эксперимента сводитсЯ
к построению прототипа, т.е. уменьшенной версии системы. Џрототип не
обЯзан удовлетворЯть характеристикам реальных систем, обычно в
изобилии есть машинные ресурсы и программнаЯ поддержка, и в таких
условиЯх программисты и разработчики становЯтсЯ непривычно опытными,
хорошо образованными и активными. ЏоЯвлЯетсЯ цель - сделать
рабо