S
помести метадату в контракт и живи спокойно без рефлекта
Size: a a a
2020 January 31
Вキ
рефлект опционален
Вキ
но я бы не использовал рефлект, чтобы лишнее не тащить
E
функция у тебя есть
Вキ
ага, похоже на правду)
ST
я бы группировал по функциональному признаку, этот сервис относится к функционалу Purchases, значит он должен быть где то там, в модуле Purchases
По итогу сделал сделал изначальный класс абстрактным и перешел к вот такой реализации, вроде стало даже проще
S
По итогу сделал сделал изначальный класс абстрактным и перешел к вот такой реализации, вроде стало даже проще
а зачем тут наследование
DG
Теперь осталось запровайдить по токену, и получить все сервисы в другом сервисе
к слову, где про это почитать можно, не ткнете носом?
L
а зачем тут наследование
Тоже задумался
Вキ
к слову, где про это почитать можно, не ткнете носом?
о том, как это работает? думаю в официальной документации должно быть
DG
о том, как это работает? думаю в официальной документации должно быть
да, про токен и получение по токену
окай, поищу, спасибо
окай, поищу, спасибо
ST
Тоже задумался
Просто как способ сделать класс-сервис для успешной передачи его в провайдеры
E
да, про токен и получение по токену
окай, поищу, спасибо
окай, поищу, спасибо
в доке все есть
L
Просто как способ сделать класс-сервис для успешной передачи его в провайдеры
Можно воспользоваться популярной шпаргалкой: спросите себя, сущность А является сущностью Б? Если да, то скорее всего, тут подойдет наследование. Если же сущность А является частью сущности Б, то наш выбор — композиция.
E
помести метадату в контракт и живи спокойно без рефлекта
мне интересно было сделать, чтобы модно, красиво, с декоратором, но тащить рефлект и правда лишнее, все это дело сильно упрощается, если провайдеру дать пропертю-ключ
E
E
@thekiba а можно ли через ключик в метадате, но без рефлекта?)
DG
в доке все есть
Вキ
L
@stih08 так выглядит что ты не екстендишь логику