Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 170
Текст из файла (страница 170)
23.1. Обзор Эта глава является первой нз трех, призванных подробно познакомить вас с производством программного продукта, начиная с относительно общего взгляда на проектирование и заканчивая специфичными для С++ приемами и концепциями проектирования. После введения и короткого обсуждения целей и средств разработки программного обеспечения в э 23.3 эта глава состоит из двух основныл частей: й 23.4 Процесс разработки программного продукта й 23.5 Практические суждения по поводу организации разработки программного продукта В главе 24 обсуждается связь между.
проектированием и языком программирования. Глава 25 знакомит вас с некоторыми ролями, которые играют классы в организации программы с точки зрения проектирования. В целом три главы части 1Ъ' ставят своей целью соединить два метода проектирования: тот, который мнит себя независимым от языка н тот, который близоруко фокусируется на деталях. В большом проекте присутствуют обе эти крайние точки зрения, но во избежание неприятностей и чрезмерной цены разработки они должны стать составной частью единого континуума, включающего в себя и программирование, и все необходимые практические аспекты. 760 Глава 23.
Разработка и проектирование 23.2. Введение Создание любого нетривиального программного продукта представляет собой сложную и зачастую устрашающую задачу. Даже для отдельного программиста простое написание программных конструкций является лишь частью процесса. Как правило, задача написания и отладки отдельных фрагментов конечной программы кажется простой по сравнению с анализом проблемы, общим проектированием программы, созданием документации, тестированием и сопровождением, а также руководством всем этим. Естественно, можно назвать всю эту деятельность «программированием» и заявить; «Я пе занимаюсь проектированием, что выг Я только программирую». Но как бы нн называть зту активность, иногда важно сфокусироваться на ее отдельных частях — и точно так же важно иногда рассмотреть процесс целиком.
Ни детали, ни общая картина не должны теряться из виду за стремлением поскорее сдать систему — хотя довольно часто именно так и случается. Данная глава посвящена тем частям процесса разработки программ, которые не связаны с написанием и отладкой отдельных фрагментов конечной программы.
Представленное обсуждение менее конкретно и подробно, чем описание отдельных особенностей языка и специфических приемов программирования, ггредставленных в лругих разделах этой книги. Однако, это неизбежно, так как для создания хорошего программ ного продукта не может быть общих рецептов. Подробное описание типа «Как изготовить программу» можно привести для специфических хорошо понятных прикладных случаев, но не для общих областей применения. Б программировании ничем не заменишь ума, опыта и вкуса И потому данная глава предлагает только общие рекомендации, различные подходы и предостережения. Обсуждение затрудняется абстрактной природой программного продукта н тем фактом, что приемы, работающие в сравнительно небольших проектах (скажем, где олин нли лва программиста пишут 10 000 строчек программы), не обязательно распространяются на средние и большие проекты.
По этой причине некоторые мнения сформулированы применительно к менее абстрактным инженерным дисциплинам, а не к программгированггю. Полсалуйста, помните, что «доказательство по аналогии» обманчиво, и аналогии здесь используются только для иллюстрации. Рассуждения о проектировании, выраженные в терминах С++, с примерами можно найти в главах 24 и 25. Идеи, высказанные в данной главе, отражены и в языке С++, и в отдельных примерах на протяжении всей книги.
Помните также, что из-за огромного разнообразия областей применения, людей и средств разработки программного обеспечения вам не следует ожидать, что каждое сделанное здесь высказывание будет напрямую применимо к вашей текущей проблеме. Привеленные наблюления сделаны в реальных жизненных проектах и применимы к самым разным ситуациям, но их нельзя считать универсальными.
Отнеситесь к ним со здравон долей скептицизма. С++ можно использовать просто как улучшенный С. Однако при этом останутся неиспользованными самые мощные средства и особенности языка, и будет достигнута лишь малая толика тех выгод, которые дает С++. Эта глава фокусируется на подходе к проектированию, который дает возможность эффективного использования средств абстракции данных и объектно-ориентированного программирования, предлагаемых С++; такой подход часто называют обггектно-ориеггтированггыз«проект«ггроьпииел. 23.2. Введение 761 В этой главе можно выделить несколько главных тем: Самое главное при разработке программного обеспечения — ясно понимать, что вы пытаетесь построить.
Успешная разработка программного обеспечения — это дело, требующее времени. * Конструируемые нами системы стремятся оказаться на пределе сложности, доступной нам и нашим средствам. В проектировании н программировании не существует универсальных рецептов, которые могли бы заменить ум, опыт и хороший вкус.
° При разработке всякого нетривиального программного обеспечения незаменимоэкспериментирование. ° Проектирование и программирование — итеративные процессы. Нельзя строго разделить фазы создания программы, такие как проектирование, программирование и тестирование, Нельзя рассматривать программирование и проектирование, не затрагивая вопросы менеджмента. Легко недооценить приведенные утверждения — и, как правило, это дорого обходится. Абстрактные идеи, которые они воплощают, трудно претворить в практику, Необходи- мо отметить неизбежность экспериментирования. Также как судостроение, езда на ве- лосипеде или программирование, проектирование — не то искусство, которым можно овладеть.
изучая только теорию. Эта глава касается проектирования систем, которые находятся на грани возмож- ностей опыта и ресурсов разработчиков. Похоже, это в природе людей и целых орга- низаций — стараться спроектировать что-то на пределе собственных возможностей. Системы, не бросающие такого вызова, не нуждаются в особом обсуждении.
У таких проектов уже есть свои устоявшиеся средства разработки, от которых не стоит отка- зываться. Новые, лучшие средства и методы нужны только для более честолюбивых попыток. А проекты, которые «мы знаем, как делать, можно передать относитель- ным новичкам, которые этого не знают. Для проектирования и построения системы не существует 'единственно пра- вильного способа>. Я бы счел веру в «единственно правильный способ» детской болезнью, если бы ей так часто не страдали опытные программисты и проекти- ровщики.
Пожалуйста, помните, что если прием сработал у вас в прошлом году для одного проекта, зто ничуть не значит, что он будет неизменно работать у кого-нибудь другого или у вас в другом проекте. Очень важно держать ум от- крытым. Ясно, что многое в приведенном здесь обсуждении относится к разработке про- граммного обеспечения промышленного масштаба. Читатели, не вовлеченные в по- добные разработки, могут развалиться в кресле и с удовольствием посмотреть на ужасы, которых они избежали. Или они могут поискать темы, относящиеся к их сфе- ре деятельности. Нет нижнего предела размеров программ, для которых, прежде чем писать код, имеет смысл создать проект. Однако есть нижний предел, для которого годится любой частный подход к проектированию н документированию. Для рас- смотрения вопросов масштабирования обратитесь к 5 23.5.2. Самая фундаментальная проблема в разработке программного продукта — это взаимосвязь его частей.
Существует лишь один основной метод борьбы со сложно- 7б2 Глава 23. Разработка и проектирование стью — разделяй и властвуй. Если зшгачу можно разделить на две подзадачи, с которыми можно справиться по отдельности, то таким разделением проолема уже более чем наполовину решена. Этот простой принцип применим к удивительно большому множеству случаев. В частности, использование модулей и классов при проектировании системы разделяет программу на две части — реализацию и ее пользователей,— и эти две части связываются лишь одним (в идеальном случае) хорошо определенным интерфейсом. Это фундаментальный подход к борьбе с присущей программам сложностью. Аналогично, процесс проектирования программы можно разбить на независимые действия с четко определенным (в идеальном случае) взаимодействием между участвующими в проекте людьми. Это основной подход в борьбе со сложностью, внутренне присущей процессу разработки и связанным с ним человеческим отношениям.
В обоих случаях вычленение частей и определение интерфейсов между ними как раз и является тем местом, где необходим опыт и вкус. Такое вычленение — не простой механический процесс; как правило, он требует проникновения в суть, которого моя<но достичь только через полное понимание системы и выход на соответствующий уровень абстрагирования (см.
9 23.4.2, 9 24.3.1 и 9 25.3). Близорукий взгляд на программу или на процесс разработки программного продукта часто приводит к серьезным из ьянам. Отметим такясе, что ризделение производится сравнительно легко как для программ, так и для людей. Труднее обеспечить связь меясду частями, находящимися по разные стороны барьера, не разрушив сам барьер и не задушив общения, необходимого для взаимодействия. Эта глава знакомит вас с подходом, а не с полным методом проектирования. Полный формальный метод проектирования находится за пределами рассмотрения данной книги. Представленный здесь подход моя<но использовать с разной степенью формализации; он может также служить основой для различных формализаций.
Данная глава — не обзор литературы; она не пытается затронуть все темы, относящиеся к разработке программных продуктов, или познакомить вас со всеми точками зрения на разработку. Это остается за пределами данной книги. Обзор литературы можно найти в [ВоосЬ, 19941 Отметим, что используемые здесь термины являются довольно универсальными и общепринятыми. Особо «интересные» термины, такие как проекклирование (с)ез1яп), прощогпип (ргососуре) и программист (ргояга1пгпег) имеют в литературе несколько разных и зачастую противоречащих друг дру|у определений, Пожалуйста, будьте осторожны, и, основываясь на узко понятых терминах илн понятиях, смысл которых вы осознаете не вполне точно, не прочитайте здесь чего-нибудь такого, что я нн в коей мере не намеревался говорить. 23.3.