Некоторая задача обработки документа выполняется в несколько приемов, соответственно документ в процессе обработки проходит несколько стадий. Каждая стадия обработки выполняется отдельным программным модулем представляющим из себя DLL. Некоторые документы ссылаются на другие документы, обработку которых нужно выполнить при обработке документа содержащего ссылку, что приводит к появлению взаимозависимых DLL, построение которых в Visual Studio неэлементарно. Что такого неправильного в приведенной постановке задачи, что ее приходится решать через одно место? Подобные взаимозависимости не приводят к каким-то особым проблемам, если модули представляет собой LIB, COM или CORBA; так может дело все же не в том, что взаимозависимости плохи сами по себе, а в том, что формат DLL был плохо продуман?
Здравствуйте, igna, Вы писали:
I>Некоторая задача обработки документа выполняется в несколько приемов, соответственно документ в процессе обработки проходит несколько стадий. Каждая стадия обработки выполняется отдельным программным модулем представляющим из себя DLL. Некоторые документы ссылаются на другие документы, обработку которых нужно выполнить при обработке документа содержащего ссылку, что приводит к появлению взаимозависимых DLL, построение которых в Visual Studio неэлементарно. Что такого неправильного в приведенной постановке задачи, что ее приходится решать через одно место? Подобные взаимозависимости не приводят к каким-то особым проблемам, если модули представляет собой LIB, COM или CORBA; так может дело все же не в том, что взаимозависимости плохи сами по себе, а в том, что формат DLL был плохо продуман?
Когда я после С++ перешел на OCaml, я в какой-то момент столкнулся с тем, что там не может быть рекурсивных модулей (по крайней мере в разных файлах). Некоторое время я поплевался: чё за фигня? А потом попилил задачу так, чтобы взаимозависимости были не нужны (обычно лечится дополнительным модулем, на который ссылаются остальные). В итоге код стал проще и понятнее.
IMHO, взаимозависимости скорее плохо, чем нет, т.к. более сложны в понимании (и, следовательно, в поддержке).
В данном конкретном случае, скорее всего также можно вынести некий отдельный модуль-загрузчик обработчиков документов, и всем модулям общаться не напрямую, а через него. По сути, тот же COM с реестром.
Здравствуйте, vshabanov, Вы писали:
V>IMHO, взаимозависимости скорее плохо, чем нет, т.к. более сложны в понимании (и, следовательно, в поддержке).
Верно, и нужно по возможности пытаться обходиться без них. Но бывают случаи.
V>В данном конкретном случае, скорее всего также можно вынести некий отдельный модуль-загрузчик обработчиков документов, и всем модулям общаться не напрямую, а через него. По сути, тот же COM с реестром.
Вот именно, бывают конкретные случаи, где взаимозависимости не то чтобы плохи или наоборот хороши, а они есть и никуда их не деть. Но вместо того, чтобы просто вздохнуть и сказать, что мол, чтож, будем использовать взаимозависимости раз так, и продолжить заниматься задачей, приходится сначала потратить некоторое количество времени на поиск обходного пути.
I>Почему может иметь смысл разъединять единица деплоинга, если одна из них не может жить без другой?
Если A жить не может без B, но B не нужен A -- то их разделение имеет глубокий смысл: в некоторых случаях ограниченной функциональности мы можем обойтись без A вообще.
Здравствуйте, K13, Вы писали:
K13>Если A жить не может без B, но B не нужен A -- то их разделение имеет глубокий смысл: в некоторых случаях ограниченной функциональности мы можем обойтись без A вообще.
Согласен, но это не единственная причина, по которой программу разделяют на DLL модули. Например, отдельные части программы могут быть написаны на разных языках и откомпилированы разными компиляторами. Совместимость DLL выше чем совместимость LIB.
Здравствуйте, igna, Вы писали:
I>Почему может иметь смысл разъединять единица деплоинга, если одна из них не может жить без другой?
Есть две причины разъединять на две компоненты.
1. Мы можем поставлять одну dll, и вообще не поставлять другую. Обратное может быть и неверно.
2. Компоненты разрабатывают разные группы. Либо они представляют набор сильносвязанных классов/функций, которые лучше отделить интерфейсом. Но в этом случае взаимозависимость — зло. Поскольку ломает слабосвязанность компонент.
В примере который ты привел, ни одной из этих причин не было замечено.
Здравствуйте, GlebZ, Вы писали:
GZ>В примере который ты привел, ни одной из этих причин не было замечено.
Не было замечено — не значит, что их там не было. Я писал например: "Каждая стадия обработки выполняется отдельным программным модулем представляющим из себя DLL." Предположим, что одна из стадий это перевод с английского на русский. По моему, достаточно нетривиальная задача, которую вполне могла бы разрабатывать отдельная группа.
Здравствуйте, igna, Вы писали:
I>Дело не в том, кто кого помогает, а в том, что взаимозависимость модулей это не обязательно плохо.
а с чего вы вдруг подумали, что это обязательно плохо?
несуществует ниодного явления — которое однозначно характеризовалось бы как "плохо", поскольку "плохо" это вещь субьективная.
Здравствуйте, igna, Вы писали:
I>Не было замечено — не значит, что их там не было. Я писал например: "Каждая стадия обработки выполняется отдельным программным модулем представляющим из себя DLL." Предположим, что одна из стадий это перевод с английского на русский. По моему, достаточно нетривиальная задача, которую вполне могла бы разрабатывать отдельная группа.
И сразу же возникают вопросы. Какая группа отвечает за интерфейсы взаимодействия? Кого будут линчевать если изменится последовательность вызовов? Что будет если нужен будет французский язык? Его тоже придется референсить к английскому так как часть интерфейса там?
I>... взаимозависимость модулей это не обязательно плохо.
Для меня взаимозависимость довольно больших и сложных объектов всегда плохо, а при командной разработке постоянные проблемы с мерджами, версиями и тп. Проще выделить отдельный объект-интерфейс (модуль и тп) использую IoC. Упрощаются сами модули, структурируются типы данных для взаимосвязи с модулями.
Здравствуйте, GlebZ, Вы писали:
GZ>И сразу же возникают вопросы. Какая группа отвечает за интерфейсы взаимодействия? Кого будут линчевать если изменится последовательность вызовов?
Эти вопросы возникают независимо от того, имеются ли взаимозависимости или нет, не так ли? Если так, то в контексте они являются демагогическими.
GZ>Что будет если нужен будет французский язык? Его тоже придется референсить к английскому так как часть интерфейса там?
Здравствуйте, igna, Вы писали:
I>Некоторая задача обработки документа выполняется в несколько приемов, соответственно документ в процессе обработки проходит несколько стадий. Каждая стадия обработки выполняется отдельным программным модулем представляющим из себя DLL. Некоторые документы ссылаются на другие документы, обработку которых нужно выполнить при обработке документа содержащего ссылку, что приводит к появлению взаимозависимых DLL, построение которых в Visual Studio неэлементарно. Что такого неправильного в приведенной постановке задачи, что ее приходится решать через одно место? Подобные взаимозависимости не приводят к каким-то особым проблемам, если модули представляет собой LIB, COM или CORBA; так может дело все же не в том, что взаимозависимости плохи сами по себе, а в том, что формат DLL был плохо продуман?
Ни формат DLL, ни сами DLL тут ни при чем. Суть твоей проблемы в косвенной рекурсии,которая существует независимо от того, существуют ли вообще DLL. А DLL — просто контейнер функций, ну и данных еще тоже, видимых за ее пределами. И таки да, косвенная рекурсия там не очень легко получается с точки зрения разработчика, но все это мелочи.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ни формат DLL, ни сами DLL тут ни при чем. Суть твоей проблемы в косвенной рекурсии,которая существует независимо от того, существуют ли вообще DLL.
Ну вообще-то будь у меня LIB вместо DLL моей проблемы не было бы.
