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

Question

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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