33. Процесс разработки по. Определение взаимосвязей. Определение интерфейсов.

1. Этап 3: выявление зависимостей

Уточните классы в плане их зависимостей. Различные виды зависимостей обсуж­даются в §24.3. В контексте проектирования ключевыми являются зависимости па­раметризация, наследования и использования. Для каждой из них важно ответить на вопрос о том, что означает, что класс ответственен за какое-то одно из свойств системы. Чтобы классу быть ответственным за что-то, ему не обязательно самому содержать все необходимые для этого данные, или непосредственно выполнять все требуемые операции. Более того, классы с фиксированной ответственностью за от­дельные свойства системы чаще всего переправляют идущие на них запросы другим классам, которые отвечают за решение частных подзадач. Естественно, тут можно переборщить и создать чрезвычайно неэффективную и труднопонимаемую архи­тектуру, в рамках которой никакая работа не делается иначе, как порождением кас­када обращений объектов за сервисом друг к другу. То, что можно сделать на месте, должно делаться сразу на этом месте.

Необходимость рассмотрения вопросов наследования и отношений использова­ния на этапе проектирования (а не реализации) вытекает из перехода от простого использования классов к представлению концепций задачи. Отсюда следует, что единицей проекта является компонент (§23.4.3, §24.4), а не индивидуальный класс.

Параметризация — часто приводящая к применения шаблонов — это способ яв­ного представления неявных зависимостей, позволяющая представить альтернати­вы без введения новых концепций. Часто имеется возможность выбора между тем, чтобы оставить что-то зависеть от контекста, или представить в виде ветви дерева наследования, или воспользоваться параметром (§24.4.1).

2. Этап 4: определение интерфейсов

Определите интерфейсы. Закрытые (private,) функции обычно не рассматривают­ся на этапе проектирования. Вопросы реализации на этапе проектирования по большей части связаны с зависимостями, возникшими на этапе 3. Кроме того, я вывел эмпирическое правило, гласящее: «если для класса не возможны по крайней мере две реализации, то с этим классом что-то не так». Это, скорее всего, не пред­ставление концепции, а замаскированная определенная реализация. Во многих случаях, рассмотрение возможности медленной эволюции класса есть приближе­ние к ответу на вопрос «достаточно ли независим интерфейс класса от реализа­ции?».

Открытые базовые классы, а также друзья класса являются частью интерфейса; см. также §11.5 и §24.4.2. Обеспечение раздельных интерфейсов для наследования и для обычных клиентов путем предоставления защищенных и открытых интер­фейсов является упражнением, заслуживающим поощрения.

На данном шаге выявляются и специфицируются точные типы аргументов. В идеале нужно стремиться к тому, чтобы максимально полно статически типизи­ровать интерфейсы в рамках типов прикладной задачи; см. §24.2.3 и §24.4.2.

В процессе определения интерфейсов выявляйте классы, чьи операции, как ка­жется, поддерживают несколько уровней абстракции. Например, некоторые функции-члены класса File могут принимать аргументы типа File descriptor, в то время как другие — строковые описания имен файлов. Операции, принимающие File descriptor, и операции, принимающие имена файлов, работают на разных уровнях абстракции, так что может возникнуть вопрос, относятся ли они к одному и тому же классу. Может лучше организовать два класса, каждый из которых под­держивает либо файловый дескриптор, либо имена файлов. В типичном случае, все операции класса должны поддерживать одинаковый уровень абстракции. Если это не так, то стоит подумать о реорганизации этого класса и родственных ему классов.