Технологии программирования
Шрифт:
Правило 2. Разработчик программного обеспечения должен знать только требуемое поведение объекта и ничего кроме этого.
Следствие принципа отделения интерфейса от реализации состоит в том, что программист может экспериментировать с различными алгоритмами, не затрагивая остальные классы объектов программы.
На этом шаге дается четкое описание классов, их данных и методов (опуская реализацию и, возможно, скрытые методы). Всем методам задаются точные типы параметров.
Идеальный интерфейс представляет
Интерфейсы классов предоставляют полную информацию для реализации классов на этапе кодирования.
Существует золотое правило: если класс не допускает, по крайней мере, двух существенно отличающихся реализаций, то что-то явно не в порядке с этим классом, это просто замаскированная реализация, а не представление абстрактного понятия. Во многих случаях для ответа на вопрос: "Достаточно ли интерфейс класса независим от реализации?" — надо указать, возможна ли для класса схема обычных вычислений.
Пытаясь провести классификацию некоторых новых объектов, задаем следующие вопросы: В чем сходство этого объекта с другими объектами общего класса? В чем его различия? Каждый класс имеет набор поведений и характеристик, которые его определяют. Начнем с верхушки фамильного дерева образца и будем спускаться по ветвям, задавая эти вопросы на протяжении всего пути. Более высокие уровни являются более общими, а вопросы — более простыми. Каждый уровень является более специфическим, чем предыдущий уровень, и менее общим.
Без сомнения, это тривиальная задача, но установить идеальную иерархию классов для определенного применения очень трудно. Прежде чем написать строку кода программы, необходимо хорошо подумать о том, какие классы необходимы и на каком уровне. По мере того как увеличивается понимание, может оказаться, что необходимы новые классы, которые фундаментально изменяют всю иерархию классов.
На втором и третьем шагах итеративной процедуры проектирования производится выявление того, насколько адекватно классы и их иерархия подходят по сути проекта. Проектировщики вынуждены реорганизовывать, улучшать проект и повторять все шаги сначала, и так до тех пор, пока качество проекта не будет удовлетворительным.
При перестройке иерархии классов применяются четыре процедуры: расщепление класса на два и более; абстрагирование (обобщение); слияние; анализ возможности использования существующих разработок.
Расщепление применяется в следующих случаях:
1) если имеется сложный класс, иногда имеет смысл разделить его на несколько простых классов и тем самым обеспечить поэтапную разработку;
2) класс содержит ряд несвязанных между собой функций или набор независимых друг от друга данных.
Обобщение —
1) общая схема использования;
2) сходство между наборами операций;
3) сходство реализаций;
4) эти классы часто фигурируют вместе в дискуссиях по проекту.
Слияние — объединение нескольких небольших, но тесно взаимодействующих классов в один. Таким образом, взаимодействие будет скрыто в реализации нового класса.
Использование существующих разработок. Обособленный класс или группа классов из уже существующего проекта может быть легко интегрирована в новый класс. Однако подобная интеграция вносит определенные ограничения в структуру системы и может сказаться на эффективности разработки самой программы. Изготовители систем объектно-ориентированного программирования поставляют системы с совместимыми библиотеками классов. Очевидно, чем больше готовых библиотечных классов будет использовано в программе, тем меньше кода придется писать при реализации программы.
В рассмотренных ранее темах не было дано настоятельных и конкретных рекомендаций по проектированию. Это соответствует убеждению, что нет "единственно верного решения". Принципы и приемы следует применять такие, которые лучше подходят для решения конкретных задач. Для этого нужен вкус, опыт и разум. Тем не менее можно указать некоторый свод правил (эвристических приемов), который разработчик может использовать в качестве ориентиров, пока не будет достаточно опытен, чтобы выработать лучшие правила. Ниже приведен свод таких эвристических правил.
Правило 1. Узнайте, что вам предстоит создать.
Правило 2. Ставьте определенные и осязаемые цели.
Правило 3. Не пытайтесь с помощью технических приемов решить социальные проблемы.
Правило 4. Рассчитывайте на большой срок в проектировании и управлении людьми.
Правило 5. Используйте существующие системы в качестве моделей, источника вдохновения и отправной точки.
Правило 6. Проектируйте в расчете на изменения: гибкость, расширяемость, переносимость, повторное использование.
Правило 7. Документируйте, предлагайте и поддерживайте повторно используемые компоненты.
Правило 8. Поощряйте и вознаграждайте повторное использование: проектов, библиотек, классов.
Правило 9. Сосредоточьтесь на проектировании компоненты.
Правило 10. Используйте классы для представления понятий.