Size: a a a

2020 August 19

L

Lee Armstrong in supapro.cxx
Побитый Кирпич
сервис локатор гавно, потому что он скрывает зависимости класса
Говорю же, вы просто не умеете его готовить.

Я его использую вот так.
Есть фарбика, которая тащит зависимости из сервис локатора и конструирует класс. И тестируемость класса осталась, и никаких неявных зависимостей.
На фрагменте кода макрос, который пишется где-нибудь в cpp файле, который регистриует фабрику (лямбду) в синглтоне и потом в другом месте можно по typeid сконструировать.
https://pastebin.com/3gU7LXj8
источник

D

Danya in supapro.cxx
Побитый Кирпич
Если это так то это тупо. Если функция принимает концепт Foo, но зовёт внутри метод bar, то на самом деле она принимает концепт FooAndBar
источник

ПК

Побитый Кирпич... in supapro.cxx
ну всё, концепты гавно значит
источник

D

Danya in supapro.cxx
Lee Armstrong
Говорю же, вы просто не умеете его готовить.

Я его использую вот так.
Есть фарбика, которая тащит зависимости из сервис локатора и конструирует класс. И тестируемость класса осталась, и никаких неявных зависимостей.
На фрагменте кода макрос, который пишется где-нибудь в cpp файле, который регистриует фабрику (лямбду) в синглтоне и потом в другом месте можно по typeid сконструировать.
https://pastebin.com/3gU7LXj8
Ну это какая-то смесь СервисЛокатора и DI контейнера
источник

ПК

Побитый Кирпич... in supapro.cxx
Мб конечно тут отмазка что это хрен провалидируешь в С++
источник

L

Lee Armstrong in supapro.cxx
Danya
Ну это какая-то смесь СервисЛокатора и DI контейнера
Не важно что это. Это разбивает ваш главный аргумент почему локатор говно.
источник

L

Lee Armstrong in supapro.cxx
Выходит что локатор все таки хорош?
источник

D

Danya in supapro.cxx
Lee Armstrong
Выходит что локатор все таки хорош?
Так это не локатор, а смесь DI контейнера и СервисЛокатора :)
источник

D

Danya in supapro.cxx
Так конечно лучше, чем сервис локатор чистый
источник

ПК

Побитый Кирпич... in supapro.cxx
Lee Armstrong
Выходит что локатор все таки хорош?
Нет, потому что у тебя всё ещё неясный интерфейс класса
источник

L

Lee Armstrong in supapro.cxx
Побитый Кирпич
Нет, потому что у тебя всё ещё неясный интерфейс класса
Почему?
источник

D

Danya in supapro.cxx
Всё равно непонятно почему надо делать Impl класс и не сделать просто SpriteManager
источник

ПК

Побитый Кирпич... in supapro.cxx
Lee Armstrong
Почему?
Класс, который принимает в конструкторе ServiceLocator это то же самое как класс принимающий в конструкторе std::any, но при этом если передашь ему не тот тип в std::any, то будет ошибка
источник

L

Lee Armstrong in supapro.cxx
Побитый Кирпич
Класс, который принимает в конструкторе ServiceLocator это то же самое как класс принимающий в конструкторе std::any, но при этом если передашь ему не тот тип в std::any, то будет ошибка
Мне кажется ты прохо прочитал что я скинул. У меня мои классы не принимают сервис локатор. Принимает фабрика. А если нужной зависимости не окажется. То этот случай обработается и до конструирования класса дело вообще не дойдет.
источник

L

Lee Armstrong in supapro.cxx
И вот Конструктор класса. Никакой неявности.
SpriteManagerImpl(std::shared_ptr<core::Logger>,
                   std::shared_ptr<service::Time>);
источник

L

Lee Armstrong in supapro.cxx
Так что сервис локатор хорош.
источник

D

Danya in supapro.cxx
Так зачем нужен Impl класс?
источник

D

Danya in supapro.cxx
Это DI контейнер, названный СервисЛокатором
источник

D

Danya in supapro.cxx
Надо называть вещи своими именами
источник

L

Lee Armstrong in supapro.cxx
Danya
Так зачем нужен Impl класс?
Влом исправлять, не более
источник