straustrup2 (852740), страница 90
Текст из файла (страница 90)
Возможно это нормально, но обычно этосвидетельствует о том, что определение слишком низкого уровня абстракции. Массив целых неявляется достаточным определением, так как неизвестно из скольких он может состоятьэлементов.-Функции set_a() и get_a(), по всей видимости, раскрывают представление объектов класса X,разрешая прямой доступ к X::a.332Бьерн Страуструп.Язык программирования С++Здесь функции-члены образуют интерфейс на слишком низком уровне абстракции.
Как правило классыс интерфейсом такого уровня относятся к специфике реализации большого компонента, если онивообще могут к чему-нибудь относиться. В идеале параметр функции из интерфейса долженсопровождаться такой информацией, которой достаточно для его понимания. Можно сформулироватьтакое правило: надо уметь передавать запросы на обслуживание удаленному серверу по узкому каналу.Язык С++ раскрывает представление класса как часть интерфейса. Это представление может бытьскрытым (с помощью private или protected), но обязательно доступным транслятору, чтобы он могразместить автоматические (локальные) переменные, сделать подстановку тела функции и т.д.Отрицательным следствием этого является то, что использование типов классов в представлениикласса может привести к возникновению нежелательных зависимостей.
Приведет ли использованиечленов типа Y и Z к проблемам, зависит от того, каковы в действительности типы Y и Z. Если этодостаточно простые типы, наподобие complex или String, то их использование будет вполнедопустимым в большинстве случаев. Такие типы можно считать устойчивыми, и необходимостьвключать определения их классов будет вполне допустимой нагрузкой для транслятора.
Если же Y и Zсами являются классами интерфейса большого компонента (например, типа графической системы илисистемы обеспечения банковских счетов), то прямую зависимость от них можно считать неразумной. Втаких случаях предпочтительнее использовать член, являющийся указателем или ссылкой:class X {Y* a;Z& b;// ...};При этом способе определение X отделяется от определений Y и Z, т.е. теперь определение X зависиттолько от имен Y и Z. Реализация X, конечно, будет по-прежнему зависеть от определений Y и Z, но этоуже не будет оказывать неблагоприятного влияния на пользователей X.Вышесказанное иллюстрирует важное утверждение: У интерфейса, скрывающего значительный объеминформации (что и должен делать полезный интерфейс), должно быть существенно меньшезависимостей, чем у реализации, которая их скрывает.
Например, определение класса X можнотранслировать без доступа к определениям Y и Z. Однако, в определениях функций-членов класса X,которые работают со ссылками на объекты Y и Z, доступ к определениям Y и Z необходим. При анализезависимостей следует рассматривать раздельно зависимости в интерфейсе и в реализации. В идеаледля обоих видов зависимостей граф зависимостей системы должен быть направленным нецикличнымграфом, что облегчает понимание и тестирование системы. Однако, эта цель более важна и чащедостижима для реализаций, чем для интерфейсов.Отметим, что класс определяет три интерфейса:class X {private:// доступно только для членов и друзейprotected:// доступно только для членов и друзей, а также// для членов и друзей производных классовpublic:// общедоступно};Члены должны образовывать самый ограниченный из возможных интерфейсов.
Иными словами, члендолжен быть описан как private, если нет причин для более широкого доступа к нему; если же таковыеесть, то член должен быть описан как protected, если нет дополнительных причин задать его как public.В большинстве случаев плохо задавать все данные, представляемые членами, как public. Функции иклассы, образующие общий интерфейс, должны быть спроектированы таким образом, чтобыпредставление класса совпадало с его ролью в проекте как средства представления понятий.Напомним, что друзья являются частью общего интерфейса.Отметим, что абстрактные классы можно использовать для представления понятия упрятывания болеевысокого уровня ($$1.4.6, $$6.3, $$13.3).333Бьерн Страуструп.Язык программирования С++12.5 Свод правилВ этой главе мы коснулись многих тем, но, как правило, избегали давать настоятельные и конкретныерекомендации по рассматриваемым вопросам.
Это отвечает моему убеждению, что нет "единственноверного решения". Принципы и приемы следует применять способом, наиболее подходящим дляконкретной задачи. Здесь требуются вкус, опыт и разум. Тем не менее, можно предложить свод правил,которые разработчик может использовать в качестве ориентиров, пока не приобретет достаточноопыта, чтобы выработать лучшие. Этот свод правил приводится ниже.Он может служить отправной точкой в процессе выработки основных направлений проекта конкретнойзадачи, или же он может использоваться организацией в качестве проверочного списка. Подчеркну ещераз, что эти правила не являются универсальными и не могут заменить собой размышления.•Нацеливайте пользователя на применение абстракции данных и объектно-ориентированногопрограммирования.-Постепенно переходите на новые методы, не спешите.-Используйте возможности С++ и методы объектно-ориентированного программированиятолько по мере надобности.•Добейтесь соответствия стиля проекта и программы.•Концентрируйте внимание на проектировании компонента.•Используйте классы для представления понятий.•-Используйте общее наследование для представления отношений "есть".-Используйте принадлежность для представления отношений "имеет".-Убедитесь, что отношения использования понятны, не образуют циклов, и что число ихминимально.-Активно ищите общность среди понятий области приложения и реализации, и возникающие врезультате более общие понятия представляйте как базовые классы.Определяйте интерфейс так, чтобы открывать минимальное количество требуемой информации:-Используйте, всюду где это можно, частные данные и функции-члены.-Используйте описания public или protected, чтобы отличить запросы разработчикапроизводных классов от запросов обычных пользователей.-Сведите к минимуму зависимости одного интерфейса от других.-Поддерживайте строгую типизацию интерфейсов.-Задавайте интерфейсы в терминах типов из области приложения.Дополнительные правила можно найти $$11.5.334Бьерн Страуструп.Язык программирования С++ГЛАВА 13.
ПРОЕКТИРОВАНИЕ БИБЛИОТЕКПроект библиотеки - это проект языка,(фольклор фирмы Bell Laboratories)... и наоборот.- А. КенигЭта глава содержит описание различных приемов, оказавшихся полезными при создании библиотек дляязыка С++. В частности, в ней рассматриваются конкретные типы, абстрактные типы, узловые классы,управляющие классы и интерфейсные классы. Помимо этого обсуждаются понятия обширногоинтерфейса и структуры области приложения, использование динамической информации о типах иметоды управления памятью.
Внимание акцентируется на том, какими свойствами должны обладатьбиблиотечные классы, а не на специфике языковых средств, которые используются для реализациитаких классов, и не на определенных полезных функциях, которые должна предоставлять библиотека.13.1 ВведениеРазработка библиотеки общего назначения - это гораздо более трудная задача, чем создание обычнойпрограммы. Программа - это решение конкретной задачи для конкретной области приложения, тогда какбиблиотека должна предоставлять возможность решение для множества задач, связанных с многимиобластями приложения.
В обычной программе позволительны сильные допущения об ее окружении,тогда как хорошую библиотеку можно успешно использовать в разнообразных окружениях,создаваемых множеством различных программ. Чем более общей и полезной окажется библиотека, темв большем числе окружений она будет проверяться, и тем жестче будут требования к ее корректности,гибкости, эффективности, расширяемости, переносимости, непротиворечивости, простоте, полноте,легкости использования и т.д. Все же библиотека не может дать вам все, поэтому нужен определенныйкомпромисс. Библиотеку можно рассматривать как специальный, интересный вариант того, что впредыдущей главе мы называли компонентом.
Каждый совет по проектированию и сопровождениюкомпонентов становится предельно важным для библиотек, и, наоборот, многие методы построениябиблиотек находят применение при проектировании различных компонентов.Было бы слишком самонадеянно указывать как следует конструировать библиотеки. В прошломоказались успешными несколько различных методов, а сам предмет остается полем активныхдискуссий и экспериментов.
Здесь только обсуждаются некоторые важные аспекты этой задачи ипредлагаются некоторые приемы, оказавшиеся полезными при создании библиотек. Не следуетзабывать, что библиотеки предназначены для совершенно разных областей программирования,поэтому не приходится рассчитывать, что какой-то один метод окажется наиболее приемлемым длявсех библиотек. Действительно, нет никаких причин полагать, что методы, оказавшиеся полезными приреализации средств параллельного программирования для ядра многопроцессорной операционнойсистемы, кажутся наиболее приемлемыми при создании библиотеки, предназначенной для решениянаучных задач, или библиотеки, представляющей графический интерфейс.Понятие класса С++ может использоваться самыми разными способами, поэтому разнообразие стилейпрограммирования может привести к беспорядку. Хорошая библиотека для сведения такого беспорядкак минимуму обеспечивает согласованный стиль программирования, или, по крайней мере, несколькотаких стилей.
Этот подход делает библиотеку более "предсказуемой", а значит позволяет легче ибыстрее изучить ее и правильно использовать. Далее описываются пять "архитипичных" классов, иобсуждаются присущие им сильные и слабые стороны: конкретные типы ($$13.2), абстрактные типы($$13.3), узловые классы ($$13.4), интерфейсные классы ($$13.8), управляющие классы ($$13.9). Всеэти виды классов относятся к области понятий, а не являются конструкциями языка.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
