DP
Потому что нельзя написать
new MyConcreteBuilderFactoryFactory()Size: a a a
2021 January 28
AT
Это нормально с точки зрения ооп дизайна класса присваивать какую-то дефолтную реализацию сервиса в конструкторе без параметров и позволять инжектить какую-то другую реализацию в контрукторе с параметром?
нет
I
Не понял причём тут нули. У него есть условно класс, там поле IBlabla {get;} = new DefaultBlaBla(). И есть 2 конструктора: () и (IBlaBla blabla). Почему не сделать 1 конструктор и просто кидать туда DefaultBlaBla
DP
Не понял причём тут нули. У него есть условно класс, там поле IBlabla {get;} = new DefaultBlaBla(). И есть 2 конструктора: () и (IBlaBla blabla). Почему не сделать 1 конструктор и просто кидать туда DefaultBlaBla
Тут вроде про другое речь
I
Ну я так понял по крайней мере :/
DP
Типа можно написать 2 конструктора vs 1 конструктор с дефолтным параметром
DP
Я так понял)
AT
потому что DI либо есть, либо его нет
AT
а на полшишечки — это архитектурный провал
DP
public MySeriousEnterpriseConstructor()
public MySeriousEnterpriseConstructor(IMyseriousEnterpriseDependency dep)AT
Типа можно написать 2 конструктора vs 1 конструктор с дефолтным параметром
DI-контейнеру что выбирать?
DP
vs
public MySeriousEnterpriseConstructor(IMyseriousEnterpriseDependency dep = null)DP
DI-контейнеру что выбирать?
Так они умеют
DP
Вроде обычно выбирают тот где больше параметров
I
vs
public MySeriousEnterpriseConstructor(IMyseriousEnterpriseDependency dep = null)Ну а смысл от такого конструктора?
I
Чтобы потом внутри чекнуть dep ??= magic ? :/
DP
Вообще не все можно инстанциировать с помощью DI
AT
Вообще не все можно инстанциировать с помощью DI
если так, то у тебя проблемы в другой плоскости
DP
Чтобы потом внутри чекнуть dep ??= magic ? :/
Ну типа можешь передать а можешь и нет
DP
если так, то у тебя проблемы в другой плоскости
Я про то что не все обязательно инстанциировать с помощью DI