AM
ListenersCollection?
Size: a a a
2020 August 10
AM
тогда да, обе проблемы уходят
DS
ListenersCollection?
НАзвание сам придумай
AM
НАзвание сам придумай
Ещё вариант пришёл в голову. Сделать Provider иммутабельным. Но, конечно, тогда не так явно.
DS
Ещё вариант пришёл в голову. Сделать Provider иммутабельным. Но, конечно, тогда не так явно.
Опять будет нарушение интерфейса. Вариант с передачей коллекции в конструктор самое то. Закрывает твою потребность добавлять листенеры через attach и не дает конфижить рантайм.
DS
Если мы декларируем следование паттерну depenedency injection, то мы должны придерживаться два простых правила:
1. Однин класс - один интерфейс.
2. Все публичные методы класса являются частью интерфейса.
1. Однин класс - один интерфейс.
2. Все публичные методы класса являются частью интерфейса.
AM
1. Или final.
DS
1. Или final.
Файнал каким боком?
AM
ну если мы 100% уверены что нам не нужен тут интерфейс и не хотим позволить менять, то final
AM
запилил
DS
ну если мы 100% уверены что нам не нужен тут интерфейс и не хотим позволить менять, то final
Ну, это уже другая история. Там речь идет исключительно касательно интерфейсов. Чтобы не делали как я приводил выше пример с сервисом.
DS
DS
@samdark, в провайдере нельзя делать валидацию коллейблов, вынеси валидатор в отдельный класс как я где-то в issue писал
AM
AM
Контейнер не готов?
AM
AM
да, что-то конфиг стал похож на задницу после этого всего :)
DS
Можно, почему нет?
Да, не все зависимости там еще есть, после этого провайдера еще могут провайдеры быть
AM
Да, не все зависимости там еще есть, после этого провайдера еще могут провайдеры быть
Тогда не ясно, что с этим вообще можно сделать...