Б. Страуструп - Язык программирования С++ (1119446), страница 78

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

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

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

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

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

Здесь подгонку обычно облегчает эффективное использование производных классов. Ноне рассчитывайте провести произвольные расширения в проекте без определенного предвидения иликооперации с создателем таких классов.Когда исчерпается набор подходящих стандартных компонентов, проектировщик машины не спешитзаняться проектированием новых оптимальных компонентов для своей машины. Это было бы слишкомрасточительно. Допустим, что не нашлось подходящего блока кондиционирования воздуха, зато естьсвободное пространство, имеющее форму буквы L, в моторном отсеке. Возможно решение разработатьблок кондиционирования указанной формы. Но вероятность того, что блок подобной странной формыбудет использоваться в машинах другого типа (даже после значительной подгонки), крайне низка.

Этоозначает, что наш проектировщик машины не сможет разделить затраты на производство такого блокас создателями машин другого типа, а значит время жизни этого блока коротко. Поэтому стоитспроектировать блок, который найдет более широкое применение, т.е. разработать разумный проектблока, более приспособленный для подгонки, чем наше L-образное чудище.

Возможно, это потребует289Бьерн Страуструп.Язык программирования С++больших усилий, и даже придется для приспособления более универсального блока изменить общееописание проекта машины. Поскольку новый блок разрабатывался для более общего применения, чемнаше L-образное чудище, предположительно, для него потребуется некоторая подгонка, чтобыполностью удовлетворить наши пересмотренные запросы. Подобная же альтернатива возникает и упрограммиста или разработчика программного обеспечения: вместо того, чтобы создать программу,привязанную к конкретному проекту, разработчик может спроектировать новую достаточноуниверсальную программу, которая будет иметь хорошие шансы стать стандартной в определеннойобласти.Наконец, когда мы прошлись по всем стандартным компонентам, составляется "окончательное" общееописание проекта.

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

Утверждается, что указаннаяметодика разработки машин применима и для программного обеспечения. Так, в этой и следующейглавах даны приемы использования ее для С++. Тем не менее можно сказать, что сама природапрограммирования способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5). В разделе 11.4.3опровергается профессиональное предубеждение против использования описанной здесь моделипроектирования. Заметим, что модель развития программного обеспечения хорошо применима тольков расчете на большие сроки. Если ваш горизонт сужается до времени выдачи очередной версии, нетсмысла создавать и поддерживать функционирование стандартных компонентов.

Это просто приведет кизлишним накладным расходам. Наша модель рассчитана на организации со временем жизни, закоторое проходит несколько проектов, и с размерами, которые позволяют нести дополнительныерасходы и на средства проектирования, программирования, и на сопровождение проектов, и наповышение квалификации разработчиков, программистов и менеджеров.

Фактически это эскизнекоторой фабрики по производству программ. Как ни удивительно, она только масштабом отличаетсяот действий лучших программистов, которые для повышения своей производительности в течении летнакапливали запас приемов и методов проектирования, создавали инструменты и библиотеки. Похоже,что большинство организаций просто не умеет воспользоваться достижениями лучших сотрудников, какиз-за отсутствия предвидения, так и по неспособности применить эти достижения в достаточношироком объеме.Все-таки неразумно требовать, чтобы "стандартные компоненты" были стандартными универсально.Существует лишь малое число международных стандартных библиотек, а в своем большинствекомпоненты окажутся стандартными только в пределах страны, отрасли, компании, производственнойцепочки, отдела или области приложения и т.д. Просто мир слишком велик, чтобы универсальныйстандарт всех компонентов и средств был реальной или желанной целью проекта.11.3.2 Цели проектированияКаковы самые общие цели проектирования? Конечно, простота, но в чем критерий простоты? Посколькумы считаем, что проект должен развиваться во времени, т.е.

система будет расширяться, переноситься,настраиваться и, вообще, изменяться массой способов, которые невозможно предусмотреть,необходимо стремиться к такой системе проектирования и реализации, которая была бы простой сучетом, что она будет меняться многими способами. На самом деле, практично допустить, что самитребования к системе будут меняться неоднократно за период от начального проекта до выдачи первойверсии системы.Вывод таков: система должна проектироваться максимально простой при условии, что она будетподвергаться серии изменений.

Мы должны проектировать в расчете на изменения, т.е. стремиться к-гибкости,-расширяемости и-переносимостиЛучшее решение - выделить части системы, которые вероятнее всего будут меняться, в290Бьерн Страуструп.Язык программирования С++самостоятельные единицы, и предоставить программисту или разработчику гибкие возможности длямодификаций таких единиц. Это можно сделать, если выделить ключевые для данной задачи понятия ипредоставить класс, отвечающий за всю информацию, связанную с отдельным понятием (и только сним). Тогда изменение будет затрагивать только определенный класс.

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

Оно подходит для многих ограниченныхприложений. Но оно не является достаточно общим, поскольку существует много способовпредставления облака: детальная картина, набросок очертаний, пиктограмма, карта и т.п. Другимисловами, вид облака определяется как им самим, так и его окружением.Второе решение заключается в том, чтобы предоставить самому облаку для его изображения сведенияо его окружении. Оно годится для большего числа случаев. Однако и это не общее решение. Если мыпредоставляем облаку сведения об его окружении, то нарушаем основной постулат, который требует,чтобы класс отвечал только за одно понятие, и каждое понятие воплощалось определенным классом.Может оказаться невозможным предложить согласованное определение "окружения облака", поскольку,вообще говоря, как выглядит облако зависит от самого облака и наблюдателя.

Чем представляетсяоблако мне, сильно зависит от того, как я смотрю на него: невооруженным глазом, с помощьюполяризационного фильтра, с помощью метеорадара и т.д. Помимо наблюдателя и облака следуетучитывать и "общий фон", например, относительное положение солнца. К дальнейшему усложнениюкартины приводит добавление новых объектов типа других облаков, самолетов. Чтобы сделать задачуразработчика практически неразрешимой, можно добавить возможность одновременногосуществования нескольких наблюдателей.Третье решение состоит в том, чтобы облако, а также и другие объекты, например, самолеты илисолнце, сами описывали себя по отношению к наблюдателю.

Такой подход обладает достаточнойобщностью, чтобы удовлетворить большинство запросовЬ. Однако, он может привести к значительномуусложнению и большим накладным расходам при выполнении. Как, например, добиться того, чтобынаблюдатель понимал описания, произведенные облаком или другими объектами?Даже эта модель будет, по всей видимости, не достаточной для таких предельных случаев, как графикас высокой степенью разрешимости.

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

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