Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 177
Текст из файла (страница 177)
Вместо усложнения класса, являющегося для проекта основным, обычно лучше сделать его универсальным и абстрактным. В ' случае необходимости особые возможности будут представлены производными классами. Для примера обратитесь к [Магйп, 19951. Такой способ приводит к иерархии абстрактных классов, где классы рядом с корнем являются самыми общими, и от них зависит большинство других классов и функций.
Классы-листья представляют собой самые специализированные классы, и от них зависит очень немного частей программы. В качестве примера разберите окончательную версию иерархии.Ьа! Ьох Я 12.4.3, 9 12.4А). 23.4.3.6. Использование моделей Собираясь написать статью, я стараюсь подыскать подходящую модель, которой можно следовать, То есть я не сразу начинаю набирать текст, а ищу публикации по схожей теме, чтобы посмотреть, не найдется ли чего-нибудь такого, что может стать образцом для моей статьи. Если выбранным образцом оказывается моя собственная статья по данной теме, я мо)у даже оставить части текста без изменений и добавить новую информацию только там, где этого требует логика новой статьи.
Например, подобным образом написана данная книга, ос новацная на первой и второй редакциях. Крайняя степень такого способа написания — форма ! шаблон) письма. В этом случае я просто заполняю имя и, может быть, добавляю несколько строчек, чтобы «персонализировать» послание. Но сути дела, когда я пишу такие письма, я просто указываю отличия от базовой модели. Аналогичное использование существующих систем в качестве модели для новых проектов является скорее нормой, чем исключением во всех формах творческой деятельности. Когда возможно, проектирование и программирование должны базироваться на уже проделанной работе. Это ограничивает для проектировщика степени свободы и позволяет сосредоточи~ь внимание лишь иа нескольких вопросах.
Начинать большой проект «совершенно с чистого листа», может быть, замечательно, однако, стремление к возможно более точному описанию оказывает «отравляющее» действие, и в результате вы начинаете, как пьяный, блуждать среди альтернатив проектирования. Наличие модели нс обременительно, и модель не требует, чтобы ей рабски следовали — она просто освобождае~ проектировщика, позволяя ему рассматривать в данный момент только один аспект проекта. Учтите, что использование модели неизбежно, потому что любой проект вытекает из опьпа проектировщиков.
Наличие явно выраженных моделей позволяет сделать сознательный выбор, ясным образом выявить предположения, определить общий набор терминов, придать проекту первоначальную форму и повысить вероятность общности подходов среди проектировщиков. 780 Глава 23. Разработка и проектирование Естественно, выбор исходной модели — само по себе важное проектное решение, и часто оно может быть принято только после исследования потенциально допустимых моделей и тщательной оценки всех альтернатив.
Более того, во многих случаях модель подходит только с учетом того, что в ней необходимы серьезные изменения для приспособления к новому приложению. Проектирование программного продукта —. тяжелая работа, и нам нужна всяческая помощь. Мы пе должны отвергать использование моделей из-за неуместного презрения к аподражательству». Подражание — это самая искренняя форма лести, и использование для вдохновения моделей и предыдущих работ — в рамках законов о собственности и авторском праве — является допустимым приемом творческой работы во всех областях; что было хорошо для Шекспира, хорошо и для нас.
Некоторые называют такое применение моделей в проектировании «повторным использованием проектов» (дсв1йп гензе). Очевидной идеей является документирование основных элементов, появляющихся во многих проектах, а гакже описание некоторых проблем проектирования, которые эти элементы решают, и условий, при которых их можно использовать — по крайней мере об этом стоит подумать. Для описания таких универсальных и полезных элементов проекта часто используется слово образец (рагссгп), и существует литература по документированию образцов и пх использованию (например, (ба|в|па, 1994) и (Сор11еп, 1995]).
Проектировщику лучше познакомиться с распространенными образцами в данной прикладной области. Как программист, я предпочитаю образцы со связанными с ними конкретными примерами программ. Подобно большинству людей я лучше всего понимаю основную идею (в данном случае образца), когда передо мной есть конкретный пример (в данном случае фрагмент программы, иллюстрирующий применение образца). Люди, активно применяющие образцы, для общения друг с другом используют специальный набор терминов. К сожалению, это может стать своего рода жаргоном, отсекающим от понимания всех, кто не входит в круг посвященных, а, как всегда, очень ваясно обеспечить общение между людьми, работающими над разными частями проекта (9 23.3), а также между проектировшиками и программистами. Все удачные большие системы являются результатом перепроектирования некоторых меньших работающих систем. Я нс знаю исключений из атого правила. Можно привести множество примеров проектов, закончившихся неудачей, над которыми мучились годами, тратили большие средства, и наконец успешно заканчивали, но спустя годы после намеченного срока.
В таких проектах сначала непреднамеренно строилась неработаюшая система, которую потом пьпались трансформировать в работающую, но в конце концов приходилось перепроектировать все по-новому, приближаясь к первоначально поставленным целям. Это говорит о том, что наивно браться за большую систему «с нуля»ч чтобы точно следовать новейшим идеям, Чем больше и интереснее система, к которой мы стремимся, тем важнее иметь модель, с которой можно начать.
Для больших систем единственно приемлемая модель — это относительно небольшая, родствелная работаюи(ая система. 23.4.4. Экспериментирование и анализ Начиная разработку амбициозного проекта, мы нс знаем, каков лучший способ построить систему. Часто мы даже точно не знаем, что система должна делать, поскольку частности проясняются только после попыток построения, тестирования и эксплуа- 23.4. Процесс разработки ?81 тации системы. Не говоря уж о построении всей системы, как нам получить необходимую информацию, чтобы понять, какие проектные решения являются ключевыми, и оценить их последствия? Мы проводим эксперимент. Мы также анализируем проект и реализацию, кактолько у нас появляется что анализировать.
Чаще всего и с большой пользой мы обсужлаем альтернативные проект н реализацию. Во всех слу <аях, кроме редчайших, проектирование — это коллективная деятельность, в которой проекты развиваются путем их представления и обсуждения. Часто самым важным инструментом в проектировании выступает классная доска; без нее находящиеся в зародышевом состоянии концепции не могут развиться и стать общим достоянием проектировщиков и программистов. Похоже, что самая распространенная форма эксперимента состоит в построении прототипа.
то есть уменыпенной версии всей системы или ее части. Прототип не имеет строгих критериев быстродействия, и ресурсов оборудования, как правило, для него вполне хватает, а проектировщики и программисты получают образование, опыт и стимул к работе. Идея заключается в том, чтобы как можно быстрее произвести работающую версию, и тем самым сделать возможным исследование проекта и выбор реализации. При хорошем исполнении этот подход может оказаться очень удачным. С другой стороны, ои может служить оправданием небрежности.
Трудность заключается в том, что цель прототипа может легко сместиться от «исследования альтернатив» на «получение какой-нибудь работающей системы как можно скорее». Это запросто уведет нас от интереса к внутренней структуре прототипа («в конце концов, это всего лишь прототип»), и чревато пренебрежением к проектированию ради забав с реализацией прототипа. Опасность таится в том, что подобная реализация может выродиться в худший сорт пожирателя ресурсов и кошмар при сопровождении, в то же время давая иллюзию «почти завершенной» системы. По определению прототип не имеет внутренней структуры, эффективности и инфраструктуры сопровождения, позволяющих спроецировать его на реальное приложение. Поэтому «прототип», превратившись в «почти продукт, поглощает время и энергию, которые было бы лучше потратить на сам продукт.
Существует соблазн как для разработчиков, так и для руководства, превратить прототип в готовый продукт и отложить «вопросы производительности» до следующего выпуска. Такая порочная практика перечеркивает все принципы проектирования. Родственная проблема порождается тем, что разработчики прототипа влюбляются в свои средства. Они могут забыть, что производственная система не всегда может позволить себе оплачивать стоимость этих средств, и что свободу от ограничений и формальностей, царящую в их маленьком исследовательском коллективе, нелегко поддержать для более многочисленной группы разработчиков, работающих по жесткому графику.
С другой стороны, прототип может принести неоценимую пользу. Рассмотрим разработку интерфейса. В данном случае внутренняя структура части системы, не взаимодействующей напрямую с пользователем, в самом деле не имеет значения, и нет другого реального пути получить опыт, кроме как дать пользователю возможность посмотреть и «пощупать систему руками». Другой пример — прототип, спроектированный именно для того, чтобы изучить внутреннюю работу системы.
Здесь рулиментом окажется пользовательский интерфейс — вполне можно вместо реальных пользователей имитировать условных. 782 Глава 23. Разработка и проектирование Создание прототипа — это вид экспериментирования. Желаемый результат— не сам прототип, а проникновение в проблему, даваемое его построением. Может быть, самым важным критерием для прототипа является то, что он должен ос гаться настолько незавершенным, чтобы было очевидным, что это всего лишь экспериментальный аппарат, который нельзя превратить в готовый продукт без серьезной переделки проекта и реализации.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
