Б. Страуструп - Язык программирования С++ (1119446), страница 79
Текст из файла (страница 79)
Я думаю, что для получения очень детальной картины нужен другойуровень абстракции.Дождевые облака - это не тот объект, который часто встретишь в программах, но объекты, участвующиев различных операциях ввода и вывода, встречаются часто. Поэтому можно считать пример с облакомпригодным для программирования вообще и для разработки библиотек в частности. Логически схожийпример в С++ представляют манипуляторы, которые используются для форматирования вывода впотоковом вводе-выводе ($$10.4.2).
Заметим, что третье решение не есть "верное решение", это простоболее общее решение. Разработчик должен сбалансировать различные требования системы, чтобынайти уровень общности и абстракции, пригодный для данной задачи в данной области. Золотоеправило: для программы с долгим сроком жизни правильным будет самый общий уровень абстракции,который вам еще понятен и который вы можете себе позволить, но не обязательно абсолютно общий.Обобщение, выходящее за пределы данного проекта и понятия людей, в нем участвующих, можетпринести вред, т.е.
привести к задержкам, неприемлемым характеристикам, неуправляемым проектам ипросто к провалу.Чтобы использование указанных методов было экономично и поддавалось управлению,проектирование и управление должно учитывать повторное использование, о чем говорится в $$11.4.1и не следует совсем забывать об эффективности (см.
$$11.3.7).11.3.3 Шаги проектированияРассмотрим проектирование отдельного класса. Обычно это не лучший метод. Понятия не существуютизолированно, наоборот, понятие определяется в связи с другими понятиями. Аналогично и класс несуществует изолированно, а определяется совместно с множеством связанных между собой классов.Это множество часто называют библиотекой классов или компонентом. Иногда все классы компонента291Бьерн Страуструп.Язык программирования С++образуют единую иерархию, иногда это не так (см. $$12.3).Множество классов компонента бывают объединены некоторым логическим условием, иногда это общий стиль программирования или описания, иногда - предоставляемый сервис. Компонент являетсяединицей проектирования, документации, права собственности и, часто, повторного использования.
Этоне означает, что если вы используете один класс компонента, то должны разбираться во всех и уметьприменять все классы компонента или должны подгружать к вашей программе модули всех классовкомпонента. В точности наоборот, обычно стремятся обеспечить, чтобы использование класса вело кминимуму накладных расходов: как машинных ресурсов, так и человеческих усилий. Но дляиспользования любого класса компонента нужно понимать логическое условие, которое его определяет(можно надеяться, что оно предельно ясно изложено в документации), понимать соглашения и стиль,примененный в процессе проектирования и описания компонента, и доступный сервис (если он есть).Итак, перейдем к способам проектирования компонента.
Поскольку часто это непростая задача, имеетсмысл разбить ее на шаги и, сконцентрировавшись на подзадачах, дать полное и последовательноеописание. Обычно нет единственно правильного способа разбиения. Тем не менее, ниже приводитсяописание последовательности шагов, которая пригодилась в нескольких случаях:[1]Определить понятие / класс и установить основные связи между ними.[2]Уточнить определения классов, указав набор операций для каждого.[3][a]Провести классификацию операций.
В частности уточнить необходимость построения,копирования и уничтожения.[b]Убедиться в минимальности, полноте и удобстве.Уточнить определения классов, указав их зависимость от других классов.[a]Наследование.[b]Использование зависимостей.[4] Определить интерфейсы классов.[a]Поделить функции на общие и защищенные.[b]Определить точный тип операций класса.Отметим, что это шаги итеративного процесса. Обычно для получения проекта, который можноуверенно использовать для первичной реализации или повторной реализации, нужно несколько разпроделать последовательность шагов. Одним из преимуществ глубокого анализа и предложенной здесьабстракцииданныхоказывается относительная легкость, с которой можно перестроитьвзаимоотношения классов даже после программирования каждого класса. Хотя это никогда не бываетпросто.Далее следует приступить к реализации классов, а затем вернуться, чтобы оценить проект, исходя изопыта реализации.
Рассмотрим эти шаги в отдельности.11.3.3.1 Шаг 1: определение классовОпределите понятия/классы и установите основные связи между ними. Главное в хорошем проекте прямо отразить какое-либо понятие "реальности", т.е. уловить понятие из области приложения классов,представить взаимосвязь между классами строго определенным способом, например, с помощьюнаследования, и повторить эти действия на разных уровнях абстракции. Но как мы можем уловить этипонятия? Как на практике решить, какие нам нужны классы?Лучше поискать ответ в самой области приложения, чем рыться в программистском хранилищеабстракций и понятий. Обратитесь к тому, кто стал экспертом по работе в некогда сделанной системе, атакже к тому, кто стал критиком системы, пришедшей ей на смену.
Запомните выражения того и другого.Часто говорят, что существительные играют роль классов и объектов, используемых в программе, этодействительно так. Но это только начало. Далее, глаголы могут представлять операции над объектамиили обычные (глобальные) функции, вырабатывающие новые значения, исходя из своих параметров,или даже классы. В качестве примера можно рассматривать функциональные объекты, описанные в292Бьерн Страуструп.Язык программирования С++$$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] Рассмотрите, какой общности именования и функциональности можно достигнуть для всехклассов компонента.Очевидно, что это - стратегия минимализма. Гораздо проще добавлять любую функцию, приносящуюощутимую пользу, и сделать все операции виртуальными. Но, чем больше функций, тем большевероятность, что они не будут использоваться, наложат определенные ограничения на реализацию изатруднят эволюцию системы. Так, функции, которые могут непосредственно читать и писать впеременную состояния объекта из класса, вынуждают использовать единственный способ реализации изначительно сокращают возможности перепроектирования.