Здравствуйте, Ikemefula, Вы писали:

E>>Или же этот реестр будет хранить что-то вроде void*, а затем будет иметься кошмарный интерфейс вида reestr::get<LogSystem>()->log("bla bla")

I>Реестр будет хранить то, что в него напихал конфигуратор.

Ну и как напиханное получать?

E>>И чем такой подход лучше?

I>слабая связанность, теструемость, реюзабельность, прозрачность

Хорошо. Давайте на примере. Чем запись LogSystem::get() лучше reestr::get()->get<LogSystem>() ?

Как именно это улучшает:
— связность (ведь клиенты лога по прежнему должны иметь доступ к его интерфейсу + теперь еще и к интерфейсу реестра)?
— тестируемость (ведь лог пишет в указанные ему обработчики, надо проверить взаимодействие класса и лога — просто создаем спец обработчик для тестов и анализируем, что ему пришло)?
— реюзабельность (система логирования вполне устоявшаяся штука, реюзается из проекта в проект; вы же предлагаете вместе с ней реюзать еще и реестр)?
— прозрачность (чем непрозрачна обычная система логирования, зачем привлекать еще и специальный реестр)?

Здравствуйте, enji, Вы писали:

I>>Реестр будет хранить то, что в него напихал конфигуратор.

E>Ну и как напиханное получать?

Через публичный интерфейс.

I>>слабая связанность, теструемость, реюзабельность, прозрачность

E>Хорошо. Давайте на примере. Чем запись LogSystem::get() лучше reestr::get()->get<LogSystem>() ?

Давай, только посмотри мои примеры в этом топике, а то мне кажется ты не понимаешь то о чем я тебе говорю.

E>Как именно это улучшает:
E> — связность (ведь клиенты лога по прежнему должны иметь доступ к его интерфейсу + теперь еще и к интерфейсу реестра)?

При чем здесь лог твой ? Еть компонент например для рендеринга, который использует логирование.

вот этот компонент не должен иметь никаких лишних зависимостей, как система логирования и тд.

E> — тестируемость (ведь лог пишет в указанные ему обработчики, надо проверить взаимодействие класса и лога — просто создаем спец обработчик для тестов и анализируем, что ему пришло)?

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

E> — реюзабельность (система логирования вполне устоявшаяся штука, реюзается из проекта в проект; вы же предлагаете вместе с ней реюзать еще и реестр)?

Опять же речь про компонент, а не про твой лог.

Компонент должен быть реюзабельным и не зависеть от лога и тд.

E> — прозрачность (чем непрозрачна обычная система логирования, зачем привлекать еще и специальный реестр)?

Код использующий самые разные синглтоны непрозрачный.

Здравствуйте, Ikemefula, Вы писали:

E>>Хорошо. Давайте на примере. Чем запись LogSystem::get() лучше reestr::get()->get<LogSystem>() ?

I>Давай, только посмотри мои примеры в этом топике, а то мне кажется ты не понимаешь то о чем я тебе говорю.

Да видел я их

E>>Как именно это улучшает:
E>> — связность (ведь клиенты лога по прежнему должны иметь доступ к его интерфейсу + теперь еще и к интерфейсу реестра)?

I>При чем здесь лог твой ? Еть компонент например для рендеринга, который использует логирование.

I>вот этот компонент не должен иметь никаких лишних зависимостей, как система логирования и тд.

Компонент для рендеринга, который использует логирование — он как получает ссылку на лог-систему? Ты где-то выше приводил пример — или через конструктор или через метод set_log
Ну т.е. если иметь пару десятков разных компонент, которым нужно логирование, то их надо переделать так, чтобы они имели ссылку на лог-систему и как-то ее устанавливать при их создании. Я правильно понял?

Здравствуйте, enji, Вы писали:

E>Здравствуйте, Ikemefula, Вы писали:

E>>>Хорошо. Давайте на примере. Чем запись LogSystem::get() лучше reestr::get()->get<LogSystem>() ?

I>>Давай, только посмотри мои примеры в этом топике, а то мне кажется ты не понимаешь то о чем я тебе говорю.

E>Да видел я их

E>>>Как именно это улучшает:
E>>> — связность (ведь клиенты лога по прежнему должны иметь доступ к его интерфейсу + теперь еще и к интерфейсу реестра)?

I>>При чем здесь лог твой ? Еть компонент например для рендеринга, который использует логирование.

I>>вот этот компонент не должен иметь никаких лишних зависимостей, как система логирования и тд.

E>Компонент для рендеринга, который использует логирование — он как получает ссылку на лог-систему? Ты где-то выше приводил пример — или через конструктор или через метод set_log
E> Ну т.е. если иметь пару десятков разных компонент, которым нужно логирование, то их надо переделать так, чтобы они имели ссылку на лог-систему и как-то ее устанавливать при их создании. Я правильно понял?

вдогонку:

или же они должны зависеть от единственного синглтона reestr и брать лог-систему у него

Здравствуйте, enji, Вы писали:

E> Ну т.е. если иметь пару десятков разных компонент, которым нужно логирование, то их надо переделать так, чтобы они имели ссылку на лог-систему и как-то ее устанавливать при их создании. Я правильно понял?

да, один из способов это service locator — компонент вытягивает и инициализирует свои депенденсы сам. Компоненту нужно передать только указатель на интерфейс вроде IServiceLocator.

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

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

Здравствуйте, Ikemefula, Вы писали:

I>да, один из способов это service locator — компонент вытягивает и инициализирует свои депенденсы сам. Компоненту нужно передать только указатель на интерфейс вроде IServiceLocator.

I>Второй способ — инжекция, компонент выставляет наружу методы для инициализации депенденсов, соответвенно в проекте нужен компонент для инжекции.

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

Идею я понял, спасибо за разъяснения.

Но все таки применительно к логу , ИМХО, нет особого смысла в этом. Библиотека логирования довольно устоявшаяся и простая штука и врядли когда-либо будет меняться. А за счет того, что всю реальную работу выполняют обработчики, которые можно подключать совершенно произвольно или не подключать вообще, зависимость от библиотеки логирования не препятствует тестированию или повторному использованию

Здравствуйте, enji, Вы писали:

E>Но все таки применительно к логу , ИМХО, нет особого смысла в этом. Библиотека логирования довольно устоявшаяся и простая штука и врядли когда-либо будет меняться. А за счет того, что всю реальную работу выполняют обработчики, которые можно подключать совершенно произвольно или не подключать вообще, зависимость от библиотеки логирования не препятствует тестированию или повторному использованию

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

Здравствуйте, Ikemefula, Вы писали:

С учетом того, что логирует не система логирования, а обработчики:

I>В другом проекте может быть другая система логирования,
другая система логирования = другие обработчики

I> а во время тестирования может понадобиться заменить логирование например заглушкой, что бы свести к минимуму затраты на логирование.
заглушка = отсутствие обработчиков

А вообще, хочется заменить систему логирования целиком — ну подключи не файл log.cpp, а совместимый по интерфейсу файл log2.cpp

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