Запрограммированные отношения — те отношения проекта, которые не могут быть прямо представлены в виде конструкций языка. Допустим, в проекте оговорено, что каждая операция, не реализованная в классе А, должна обслуживаться объектом класса В. К запрограммированным отношениям относят также операции преобразования типов. Следует, по возможности, избегать применения этого вида отношений из-за усложнения реализации. Идеальный класс должен в минимальной степени зависеть от остального мира. Следовательно, следует стараться минимизировать зависимости.

Спрячем подробности реализации за фасадом интерфейса. Объект инкапсулирует поведение, если он умеет выполнять некоторые действия, но подробности, как это делается, остаются скрытыми за фасадом интерфейса. Эта идея была сформулирована специалистом по информатике Дэвидом Парнасом в виде правил, которые часто называются принципами Парнаса.

Правило 1. Разработчик программы должен предоставлять пользователю всю информацию, которая нужна для эффективного использования приложения, и ничего кроме этого.

Правило 2. Разработчик программного обеспечения должен знать только требуемое поведение объекта и ничего кроме этого.

Следствие принципа отделения интерфейса от реализации состоит в том, что программист может экспериментировать с различными алгоритмами, не затрагивая остальные классы объектов программы.

На этом шаге дается четкое описание классов, их данных и методов (опуская реализацию и, возможно, скрытые методы). Всем методам задаются точные типы параметров.

Идеальный интерфейс представляет пользователю полный и последовательный набор понятий; согласован со всеми частями компоненты; не открывает подробности реализации и может быть реализован различными способами; ограниченно и четко определенным образом зависит от других интерфейсов.

Интерфейсы классов предоставляют полную информацию для реализации классов на этапе кодирования.

Существует золотое правило: если класс не допускает, по крайней мере, двух существенно отличающихся реализаций, то что-то явно не в порядке с этим классом, это просто замаскированная реализация, а не представление абстрактного понятия. Во многих случаях для ответа на вопрос: "Достаточно ли интерфейс класса независим от реализации?" — надо указать, возможна ли для класса схема обычных вычислений.

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

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

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

При перестройке иерархии классов применяются четыре процедуры: расщепление класса на два и более; абстрагирование (обобщение); слияние; анализ возможности использования существующих разработок.

Расщепление применяется в следующих случаях:

1) если имеется сложный класс, иногда имеет смысл разделить его на несколько простых классов и тем самым обеспечить поэтапную разработку;

2) класс содержит ряд несвязанных между собой функций или набор независимых друг от друга данных.

Обобщение — выявление в группе классов общих свойств и вынесение их в общий базовый класс. Признаки необходимости обобщения таковы:

1) общая схема использования;

2) сходство между наборами операций;

3) сходство реализаций;

4) эти классы часто фигурируют вместе в дискуссиях по проекту.

Слияние — объединение нескольких небольших, но тесно взаимодействующих классов в один. Таким образом, взаимодействие будет скрыто в реализации нового класса.

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

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

Правило 1. Узнайте, что вам предстоит создать.

Правило 2. Ставьте определенные и осязаемые цели.

Правило 3. Не пытайтесь с помощью технических приемов решить социальные проблемы.

Правило 4. Рассчитывайте на большой срок в проектировании и управлении людьми.

Правило 5. Используйте существующие системы в качестве моделей, источника вдохновения и отправной точки.

Правило 6. Проектируйте в расчете на изменения: гибкость, расширяемость, переносимость, повторное использование.

Правило 7. Документируйте, предлагайте и поддерживайте повторно используемые компоненты.

Правило 8. Поощряйте и вознаграждайте повторное использование: проектов, библиотек, классов.

Правило 9. Сосредоточьтесь на проектировании компоненты.

Правило 10. Используйте классы для представления понятий.

Правило 11. Определяйте интерфейсы так, чтобы сделать открытым минимальный объем информации, требуемой для интерфейса.

Правило 12. Проводите строгую типизацию интерфейсов всегда, когда это возможно.

Правило 13. Используйте в интерфейсах типы из области приложения всегда, когда это возможно.

Правило 14. Многократно исследуйте и уточняйте как проект, так и реализацию.

Правило 15. Используйте лучшие доступные средства для проверки и анализа проекта и реализации.

Правило 16. Экспериментируйте, анализируйте и проводите тестирование на самом возможном раннем этапе.

Правило 17. Стремитесь к простоте, максимальной простоте, но не сверх того.

Правило 18. Не разрастайтесь, не добавляйте возможности "на всякий случай".

Правило 19. Не забывайте об эффективности.

Правило 20. Сохраняйте уровень формализации, соответствующий размеру проекта.

Правило 21. Не забывайте, что разработчики, программисты и даже менеджеры остаются людьми.

Б. Страуструп придумал реализацию механизма множественного наследования и при этом отвергал агрегирование, хотя и реализовал это в своем языке C++.