Как вы ведете модульную разработку на c / c ++?

Question

Я могу справиться только с самым простым случаем, когда есть только 2 модуля A и B

A зависит от B , поэтому я создаю B как библиотеку и включаю заголовочный файл B в A , также ссылка на библиотеку B при сборке A .

Это не будет работать, когда A и B взаимозависимы, и даже хуже, когда число модулей увеличивается.

Так каков общий способ выполнения модульной разработки в c/c++?

UPDATE

Извините, похоже, мой заголовок неверен, перефразированная версия: как разделить модуль на множество файлов .h и .cpp (не один)?

Answer 1

Вообще говоря, наличие двух взаимозависимых модулей - это дизайнерский запах. Вы можете либо

1) объединить модули в новый C или

2) выделить общее подмножество в I, сделав A и B зависимыми от I, но не друг от друга.

обновление

Используйте предварительные объявления и #pragma один раз или # include / # ifndef protection:

Когда я могу использовать предварительную декларацию?

Должен ли я использовать #include в заголовках?

Answer 2

Если A и B взаимозависимы, вы не можете развернуть ни один из них изолированно.Поэтому у вас практически один модуль, а не два.(Вы можете реорганизовать ваши модули, чтобы извлечь общий материал в третий модуль C, тем самым сделав так, что A и B зависят от C, но не друг от друга.)

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

Обновление

как разделить модуль на несколько файлов .h и .cpp (не один)?

Основной принцип очень похож на принцип модуля: избегайте циклических зависимостей и повторяющихся определений.@Felix уже упомянул основные инструменты для этого: отправьте декларации и включите охрану.Я также могу поддержать рекомендацию @ kotlinski о книге Лармана для более глубокого понимания темы.

Изучение хорошего дизайна требует практики, поэтому не сдавайтесь, если ваш первый подход не выглядит идеально :-) ВC ++, одна конкретная боль - чрезмерная перекомпиляция после изменений.Чтобы свести к минимуму это, старайтесь, чтобы вещи (классы, заголовки), от которых вы зависели больше всего, были теми, которые меняются реже.Т.е. зависят от интерфейсов (абстрактных классов), а не от конкретных реализаций.

Кроме того, старайтесь поддерживать здоровые отношения между логическим разделением (классы / компоненты) и физическим разделением (файлы header / cpp).Типичный способ - поместить каждое определение класса в отдельный заголовочный файл, а его реализацию (если применимо) - в отдельный файл cpp.Однако вы можете предпочесть определение тесно связанных классов (компонентов) в одном заголовке, чтобы подчеркнуть их логическую взаимосвязь.

Answer 3

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

Если вас интересует этот материал, Large Scale C ++ Software Design - хорошее чтение.

Answer 4

Шаблоны проектирования , например Модель – Вид – Контроллер - MVC.

Модель – Вид – Контроллер (MVC) - это программная архитектура, 1 в настоящее время считается архитектурным шаблоном, используемым в разработке программного обеспечения. Шаблон изолирует «доменную логику» (прикладную логику для пользователя) от ввода и представления (UI), позволяя независимую разработку, тестирование и обслуживание каждого.