22. Минимизируйте зависимости определений и избегайте циклических зависимостей

22. Минимизируйте зависимости определений и избегайте циклических зависимостей

Резюме

Избегайте излишних зависимостей. Не включайте при помощи директивы #include определения там, где достаточно предварительного объявления.

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

Обсуждение

Предпочитайте использовать предварительные объявления везде, где не требуется полное определение типа. Полное определение класса С требуется в двух основных случаях.

• Когда вам необходимо знать размер объекта С. Например, при создании объекта С в стеке или при использовании его в качестве непосредственно хранимого (не через указатель) члена другого класса.

• Когда вам требуется имя или вызов члена С. Например, когда вы вызываете функцию-член этого класса.

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

В общем случае зависимости и их циклы следует рассматривать на уровне модулей. Модуль представляет собой образующий единое целое набор совместно опубликованных классов и функций (см. рекомендацию 5). Циклическая зависимость в простейшем виде представляет собой два класса, непосредственно зависящих друг от друга

class Child; // Устранение циклической зависимости

class Parent { // ...

 Child* myChild_;

};

// возможно, в другом заголовочном файле

class Child { // ...

 Parent* myParent_;

};

Классы Parent и Child зависят друг от друга. Приведенный код компилируется, но мы сталкиваемся с фундаментальной проблемой: эти два класса больше не являются независимыми, и более того, становятся взаимозависимы друг от друга. Это не всегда плохо, но должно иметь место лишь в том случае, когда оба класса являются частями одного и того же модуля (разработанного одним и тем же человеком или командой, оттестированного и выпущенного как единое целое).

В противоположность описанной ситуации, рассмотрим, что будет, если класс Child не должен будет хранить обратную связь с объектом Parent? Тогда Child может быть выпущен в собственном отдельном небольшом модуле (и, возможно, под другим именем), полностью независимо от Parent — что, конечно, существенно повышает гибкость проектирования.

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

Чтобы разорвать циклы, примените принцип инверсии зависимостей (Dependency Inversion Principle), описанный в [Martin96a] и [Martin00] (см. также рекомендацию 36): не делайте модули высокого уровня зависящими от модулей низкого уровня; вместо этого делайте их зависимыми от абстракций. Если вы можете определить независимые абстрактные классы для Parent или Child, вы разорвете цикл. В противном случае вы должны сделать их частями одного и того же модуля.

Частный вид зависимости, от которой страдают некоторые проекты, — это транзитивная зависимость от производных классов, которая осуществляется, когда базовый класс зависит от всех своих наследников, прямых и непрямых. Ряд реализаций шаблона проектирования Visitor приводят к такому виду зависимости, которая допустима только в исключительно стабильных иерархиях. В противном случае вам лучше изменить свой проект, например, воспользовавшись шаблоном проектирования Acyclic Visitor [Martin98].

Одним из симптомов чрезмерных зависимостей является перекомпиляция больших частей проекта при внесении небольших локальных изменений (см. рекомендацию 2).

Исключения

Циклические зависимости между классами — не всегда плохо, пока классы рассматриваются как часть одного модуля и совместно тестируются и выпускаются. Простая непосредственная реализация таких шаблонов проектирования, как Command и Visitor приводят к интерфейсам, которые естественным образом оказываются взаимозависимыми. Такие зависимости можно разрушить, но это требует более четкого проектирования.

Ссылки

[Alexandrescu01] §3 • [Boost] • [Gamma95] • [Lakos96] §0.2.1, §4.6-14, §5 • [Martin96a] • [Martin96b] • [Martin98] §7 • [Martin00] • [McConnell93] §5 • [Meyers97] §46 • [Stroustrup00] §24.3.5 • [Sutter00] §26 • [Sutter02] §37 • [Sutter03]