Жертвуют ли фреймворки ведения журнала C ++ возможностью повторного использования?

Question

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

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

Жертвует ли добавление зависимости к вашей собственной платформе ведения журнала возможностью повторного использования компонента?

Answer 1

ДА.Но внедрение зависимостей поможет в этом случае.

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

Answer 2

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

Answer 3

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

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

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

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