Свод правил
В этой главе мы затронули много тем, но как правило не давали настоятельных и конкретных рекомендаций по проектированию. Это соответствует моему убеждению, что нет "единственно верного решения". Принципы и приемы следует применять тем способом, который лучше подходит для конкретных задач. Для этого нужен вкус, опыт и разум. Все-таки можно указать некоторый свод правил, который разработчик может использовать в качестве ориентиров, пока не наберется достаточно опыта, чтобы выработать лучшие. Ниже приведен свод таких правил.
Эти правила можно использовать в качестве отправной точки в процессе выработки основных направлений для проекта или организации или в качестве проверочного списка. Подчеркну еще раз, что они не являются универсальными правилами и не могут заменить размышления.
·
Узнайте, что вам предстоит создать.
· Ставьте определенные и осязаемые цели.
· Не пытайтесь с помощью технических приемов решить социальные проблемы.
· Рассчитывайте на большой срок
- в проектировании, и
- управлении людьми.
· Используйте существующие системы в качестве моделей, источника вдохновения и отправной точки.
· Проектируйте в расчете на изменения:
- гибкость,
- расширяемость,
- переносимость, и
- повторное использование.
· Документируйте, предлагайте и поддерживайте повторно используемые компоненты.
· Поощряйте и вознаграждайте повторное использование
- проектов,
- библиотек, и
В этой главе мы коснулись многих тем, но, как правило, избегали давать настоятельные и конкретные рекомендации по рассматриваемым вопросам. Это отвечает моему убеждению, что нет "единственно верного решения". Принципы и приемы следует применять способом, наиболее подходящим для конкретной задачи. Здесь требуются вкус, опыт и разум. Тем не менее, можно предложить свод правил, которые разработчик может использовать в качестве ориентиров, пока не приобретет достаточно опыта, чтобы выработать лучшие. Этот свод правил приводится ниже.
Он может служить отправной точкой в процессе выработки основных направлений проекта конкретной задачи, или же он может использоваться организацией в качестве проверочного списка. Подчеркну еще раз, что эти правила не являются универсальными и не могут заменить собой размышления.
· Нацеливайте пользователя на применение абстракции данных и объектно-ориентированного программирования.
- Постепенно переходите на новые методы, не спешите.
- Используйте возможности С++ и методы объектно-ориентированного программирования только по мере надобности.
· Добейтесь соответствия стиля проекта и программы.
· Концентрируйте внимание на проектировании компонента.
· Используйте классы для представления понятий.
- Используйте общее наследование для представления отношений "есть".
- Используйте принадлежность для представления отношений "имеет".
- Убедитесь, что отношения использования понятны, не образуют циклов, и что число их минимально.
- Активно ищите общность среди понятий области приложения и реализации, и возникающие в результате более общие понятия представляйте как базовые классы.
· Определяйте интерфейс так, чтобы открывать минимальное количество требуемой информации:
- Используйте, всюду где это можно, частные данные и функции-члены.
- Используйте описания public или protected, чтобы отличить запросы разработчика производных классов от запросов обычных пользователей.
- Сведите к минимуму зависимости одного интерфейса от других.
- Поддерживайте строгую типизацию интерфейсов.
- Задавайте интерфейсы в терминах типов из области приложения.
Дополнительные правила можно найти $$11.5.
