S
можно избегать внедрения самого локатора
Size: a a a
2020 September 11
S
тут вопрос уже в использовании
S
если везде внедрять сервис локатор, просто появляется неопределенность чего хочет класс, но если внедрять зависимости, которые разрешает локатор то все норм
S
просто тогда появляется уже прямая зависимость, а не инвертированная
S
вернее даже не так
S
мы сами будем управлять какой объект сервиса передать
S
что немного странно
НП
Так правильное использование локатора, это контейнер.
И вот теперь вопрос. Зачем создавать контейнер для маленького проекта в котором один разраб? Это бессмысленно
И вот теперь вопрос. Зачем создавать контейнер для маленького проекта в котором один разраб? Это бессмысленно
S
Так правильное использование локатора, это контейнер.
И вот теперь вопрос. Зачем создавать контейнер для маленького проекта в котором один разраб? Это бессмысленно
И вот теперь вопрос. Зачем создавать контейнер для маленького проекта в котором один разраб? Это бессмысленно
а как вообще кол-во разрабов влияет на что-то?
МЕ
Я тоже не понял
S
а если я 1 разраб , но пилю b2b систему уже 3 год
S
и она там на 100500 классов
МЕ
Я сервис пишу,один ,тоже использую контейнеры.
НП
а как вообще кол-во разрабов влияет на что-то?
Основная и единственна, задача контейнера это инстанс объектов. Так какой смысл это доверять контейнеру?
S
Основная и единственна, задача контейнера это инстанс объектов. Так какой смысл это доверять контейнеру?
для инверсии управления)
S
чтобы в любой момент не парится и сконфигурировать 1 контейнер
S
а не 100500 классов с зависимостями
НП
для инверсии управления)
Контейнер не помогает инрертировать зависимости. Не путай
S
Контейнер не помогает инрертировать зависимости. Не путай
упарвления
S
а не зависимостей