Если бы мне надо было построить мост, то я серьезно подумал бы, изкакого материала его строить, и проект моста сильно зависел бы отвыбранного материала, а, следовательно, разумные проекты каменногомоста отличаются от разумных проектов металлического моста илиот разумных проектов деревянного моста и т.д. Не стоитрассчитывать на выбор подходящего для моста материала без определенныхзнаний о материалах и их использовании. Конечно, вам не надо бытьспециалистом плотником для проектирования деревянного моста, но выдолжны знать основы конструирования из дерева, чтобы предпочесть егометаллу в качестве материала для моста. Более того, хотя дляпроектирования деревянного моста вы и не должны быть специалистомплотником, вам необходимо достаточно детально знать свойствадерева и еще больше знать о плотниках. Аналогично, при выборе языка программирования дляопределенного программного обеспечения надо знать несколько языков,а для успешного проектирования программы надо достаточно детальнознать выбранный язык реализации, даже если вам лично не предстоитнаписать ни одной строчки программы. Хороший проектировщик мостаценит свойства используемых им материалов и применяет их для улучшенияпроекта. Аналогично, хороший разработчик программ использует сильныестороны языка реализации и, насколько возможно, стремится избежать такогоего использования, которое вызовет трудности на стадии реализации. Можно подумать, что так получается естественным образом, еслив проектировании участвует только один разработчик или программист, однакодаже в этом случае программист в силу недостатка опыта или из-занеоправданной приверженности к стилю программирования, рассчитанному насовершенно другие языки, может сбиться на неверное использование языка.Если разработчик существенно отличается от программиста, особенноесли у них разная программистская культура, возможность появленияв окончательной версии системы ошибок, неэффективных и неэлегантных решенийпочти наверняка превратится в неизбежность. Итак, чем может помочь разработчику язык программирования? Онможет предоставить такие языковые средства, которые позволятвыразить прямо на языке программирования основные понятия проекта.Тогда облегчается реализация, проще поддерживать ее соответствиепроекту, проще организовать общение междуразработчиками и программистами, и появляется возможность создатьболее совершенные средства как для разработчиков, так и дляпрограммистов. Например, многие методы проектирования уделяют значительное вниманиезависимостям между различными частями программы (обычно с цельюих уменьшения и гарантии того, что эти части будут понятны и хорошоопределены). Язык, допускающий явное задание интерфейсов междучастями программы, может помочь в этом вопросеразработчикам. Он может гарантировать, что действительно будутсуществовать только предполагаемые зависимости. Посколькубольшинство зависимостей явно выражено в программе на таком языке,можно разработать средства, читающие программу и выдающие графызависимостей. В этом случае разработчику и другим исполнителям легчеуяснить структуру программы. Такие языки программирования как С++помогают сократить разрыв между проектом и программой, а значитуменьшают возможность путаницы и недопониманий. Базовое понятие С++ - это класс. Класс имеет определенныйтип. Кроме того, класс является первичным средством упрятыванияинформации. Можно описывать программы в терминах пользовательскихтипов и иерархий этих типов. Как встроенные, так и пользовательскиетипы подчиняются правилам статического контроля типов. Виртуальныефункции предоставляют, не нарушая правил статических типов,механизм связывания на этапе выполнения. Шаблоны типа позволяютсоздавать параметризованные типы. Особые ситуации позволяют сделатьрегулярной реакцию на ошибки. Все эти средства С++ можноиспользовать без дополнительных накладныхрасходов в сравнении с программой на С. Таковы главнейшиесредства С++, которые должен представлять и учитывать разработчик.Кроме того, существенно повлиять на принятие решений на стадиипроектирования может наличие доступных больших библиотекследующего назначения: для работы с матрицами, для связи сбазами данных, для поддержки параллельногопрограммирования, графические библиотеки и т.д. Страх перед новизной, непригодный здесь опыт работы на другихязыках, в других системах или областях приложения, бедные средствапроектирования - все это приводит к неоптимальному использованию С++.Следует отметить три момента, когда разработчику не удаетсяизвлечь выгоду из возможностей С++ и учесть ограничения языка:[1] Игнорирование классов и составление проекта таким образом, что программистам приходится ограничиваться только С.[2] Игнорирование производных классов и виртуальных функций, использование только подмножества абстрактных данных.[3] Игнорирование статического контроля типов и составление проекта таким образом, что программисты вынуждены применять динамические проверки типов.Обычно указанные моменты возникают у разработчиков, связанных с:[1] C, или традиционной системой CASE или методами структурного проектирования;[2] Адой или методами проектирования с помощью абстракции данных;[3] языками, близкими Smalltalk или Lisp.В каждом случае следует решить: неправильно выбран языкреализации (считая, что метод проектирования выбран верно), илиразработчику не удалось приспособиться и оценить язык (считая, чтоязык реализации выбран верно). Следует сказать, что нет ничего необычного или позорного втаком расхождении. Просто это расхождение, которое приведет кнеоптимальному проекту, возложит дополнительную работу напрограммистов, а в случае, когда структура понятий проектазначительно беднее структуры языка С++, то и на самих разработчиков. Отметим, что необязательно все программы должныструктурироваться опираясь на понятия классов и (или) иерархий классов,и необязательно всякая программа должна использовать все средства,предоставляемые С++. Как раз наоборот, для успеха проекта необходимо,чтобы людям не навязывали использование языковых средств, с которымиони только познакомились. Цель последующего изложения не в том,чтобы навязать догматичное использование классов, иерархий истрого типизированных интерфейсов, а в том, чтобы показатьвозможности их использования всюду, где позволяет областьприложения, ограничения С++ и опыт исполнителей. В $$12.1.4 будутрассмотрены подходы к различному использованию С++ в проектепод заголовком "Проект-гибрид".
Игнорирование классов
Рассмотрим первый из указанных моментов - игнорирование классов.В таком случае получившаяся программа на С++ будет приблизительноэквивалентна С-программе, разработанной по тому же проекту, и,можно сказать, что они будут приблизительно эквивалентны программамна Аде или Коболе, разработанным по нему же.По сути проект составлен как независящий от языка реализации, чтопринуждает программиста ограничиваться общим подмножеством языковС, Ада или Кобол. Здесь есть свои преимущества. Например, получившеесяв результате строгое разделение данных и программного кода позволяетлегко использовать традиционные базы данных, которые разработаныдля таких программ. Поскольку используется ограниченный языкпрограммирования, от программистов требуется меньше опытности(или, по крайней мере другой ее уровень). Для многих приложений,например, для традиционных баз данных, работающих сфайлом последовательно, такой подход вполне разумен, а традиционныеприемы, отработанные за десятилетия, вполне адекватны задаче. Однако там, где область приложения существенно отличается оттрадиционной последовательной обработки записей (или символов),или сложность задачи выше, как, например, в диалоговой системеCASE, недостаток языковой поддержки абстрактных данныхиз-за отказа от классов (если их не учитывать) повредитпроекту. Сложность задачи не уменьшится, но, поскольку системареализована на обедненном языке, структура программы плохо будетотвечать проекту. У нее слишком большой объем, не хватает проверки типов,и, вообще, она плохо приспособлена для использования различныхвспомогательных средств. Это путь, приводящий к кошмарам при еесопровождении. Обычно для преодоления указанных трудностей создают специальныесредства, поддерживающие понятия, используемые в проекте. Благодаряим создаются конструкции более высокогоуровня и организуются проверки с целью компенсировать дефекты(или сознательное обеднение) языка реализации. Так методпроектирования становится самоцелью, и для него создается специальныйязык программирования. Такие языки программирования в большинствеслучаев являются плохой заменой широко распространенных языковпрограммирования общего назначения, которые сопровождаютсяподходящими средствами проектирования. Использовать С++ с такимограничением, которое должно компенсироваться при проектированииспециальными средствами, бессмысленно. Хотя несоответствие междуязыком программирования и средствами проектирования может быть простостадией процесса перехода, а значит временным явлением. Самой типичной причиной игнорирования классов при проектированииявляется простая инерция. Традиционные языки программирования непредоставляют понятия класса, и в традиционных методах проектированияотражаются этот недостаток. Обычно в процессе проектированиянаибольшее внимание уделяется разбиению задачи на процедуры,производящие требуемые действия. В главе 1 это понятие называлосьпроцедурным программированием, а в области проектирования оноименуется как функциональная декомпозиция. Возникает типичныйвопрос "Можно ли использовать С++ совместно с методом проектирования,базирующимся на функциональной декомпозиции?" Да, можно, но,вероятнее всего, в результате вы придете к использованию С++ какпросто улучшенного С со всеми указанными выше проблемами. Этоможет быть приемлемо на период перехода на новый язык, или дляуже завершенного проектирования, или для подзадач, в которыхиспользование классов не дает существенных выгод (если учитыватьопыт программирования на С++ к данному моменту), но в общемслучае на большом отрезке времени отказ от свободногоиспользования классов, связанный с методом функциональнойдекомпозиции, никак не совместим с эффективным использованием С++. Процедурно-ориентированный и объектно-ориентированныйподходы к программированию различаются по своей сути и обычноведут к совершенно разным решениям одной задачи. Этот выводверен как для стадии реализации, так и для стадии проектирования:вы концентрируете внимание или на предпринимаемых действиях, или напредставляемых сущностях, но не на том и другом одновременно. Тогда почему метод объектно-ориентированного проектированияпредпочтительнее метода функциональной декомпозиции?Главная причина в том, что функциональная декомпозиция не даетдостаточной абстракции данных. А отсюда уже следует, что проектбудет - менее податливым к изменениям, - менее приспособленным для использования различных вспомогательных средств, - менее пригодным для параллельного развития и - менее пригодным для параллельного выполнения.Дело в том, что функциональная декомпозиция вынуждает объявлять"важные" данные глобальными, поскольку, если система структурированакак дерево функций, всякое данное, доступное двум функциям, должнобыть глобальным по отношению к ним. Это приводит к тому, что"важные" данные "всплывают" к вершине дерева, помере того как все большее число функций требует доступа к нимЬ. Ь В точности так же происходит в случае иерархии классов с однимкорнем, когда "важные" данные всплывают по направлению к базовомуклассу. Когда мы концентрируем внимание на описаниях классов, заключающихопределенные данные в оболочку, то зависимости между различнымичастями программы выражены явно и можно их проследить. Еще болееважно то, что при таком подходе уменьшается число зависимостейв системе за счет лучшей расстановки ссылок на данные. Однако, некоторые задачи лучше решаются с помощью наборапроцедур. Смысл "объектно-ориентированного" проектирования не втом, чтобы удалить все глобальные процедуры из программы илине иметь в системе процедурно-ориентированных частей. Основнаяидея скорее в том, что классы, а не глобальные процедуры становятсяглавным объектом внимания на стадии проектирования. Использованиепроцедурного стиля должно быть осознанным решением, а не решением,принимаемым по умолчанию. Как классы, так и процедуры следуетприменять сообразно области приложения, а не просто какнеизменные методы проектирования.