Среда разработки протоколов C++ жертвует повторным использованием?

Question

В C++ нет стандартного инструмента ведения журнала де-факто. По моему опыту, магазины сворачивают свои собственные. Это создает некоторую проблему, однако, при попытке создания повторно используемых компонентов программного обеспечения. Если все в вашей системе зависит от компонента протоколирования, это делает программное обеспечение менее многоразовым, в основном заставляя любые нисходящие проекты использовать вашу систему ведения журнала вместе с компонентами, которые они действительно хотят.

IOC (инъекция зависимостей) на самом деле не помогает с проблемой, так как ваши компоненты должны будут зависеть от абзаца регистрации. Компоненты протоколирования могут добавлять зависимости от ввода-вывода файлов, механизмов запуска и других возможных нежелательных зависимостей.

Добавляет ли зависимость от вашей собственной системы ведения журнала жертву за повторное использование компонента?

Answer 1

Да. Но инъекция зависимостей поможет в этом случае.

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

Answer 2

Да, Мендельт является правильным. Мы делаем именно это в наших продуктах. Все зависит от абстрактного интерфейса ILogger, но это не зависит ни от чего другого. Обычно исполняемый файл или высокоуровневая DLL будет создавать фактический реализованный интерфейс Logger и вводить его.

Answer 3

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

При инициализации регистрации в вашей библиотеке им нужно будет указать обратный вызов, а затем клей-код будет зависеть от них, чтобы он хорошо работал с тем, что у них есть.

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

Кроме того, у вызывающего абонента могут быть встроенные компоненты из библиотеки несколько раз, а также проблемы с конфликтом ресурсов или потоками, которые требуют предоставления другого обратного вызова журнала для каждого из них.