В C ++ почему циклические зависимости каталогов плохие? - PullRequest
3 голосов
/ 30 января 2012

Я спрашиваю это о проекте C ++, разработанном на Linux.Учтите это:

У меня есть два одноранговых каталога, dir1 и dir2.dir1 содержит classA.h и classB.h.dir2 содержит classC.h и classD.h.dir1/classA.h имеет #include для dir2/classC.h.dir2/classD.h имеет #include для dir1/classB.h.В результате существует циклическая зависимость между каталогами dir1 и dir2.Однако между любыми классами нет циклических зависимостей.

Я понимаю, почему циклические зависимости плохи между классами.Мне кажется, что каталоги также не должны иметь циклических зависимостей - однако я не могу понять, почему это было бы плохо.

У кого-нибудь есть объяснение?

Ответы [ 2 ]

5 голосов
/ 30 января 2012

Они не плохие.По крайней мере, не так, как вы сформулировали проблему.Каталоги предназначены для организации файлов, но программно не имеют смысла.

Однако если ваши каталоги представляют собой отдельные модули (т. Е. Существует сгенерированный файл библиотеки для каждого каталога), у вас будут ошибки компоновки.

Поскольку classA зависит от classC, вам необходимо собрать второй модуль, чтобы скомпилировать первый.Но второму модулю нужен первый модуль, который должен быть построен первым, поскольку classD зависит от classB.

0 голосов
/ 30 января 2012

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

Обслуживаемость : когда «модуль» (в данном случае каталог) имеет зависимости от другого модуля, при изменении других модулей это изменение может повлиять на этот модуль.
Повторное использование : при повторном использовании модуля необходимо также повторно использовать модули, от которых он зависит.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...