Внедрение через конструктор само по себе нормально. Риск — жёсткая зависимость от конкретного B, а в показанном primary constructor this.dependency ещё и не является объявленным полем.
Недостатки прямой зависимости через конструктор
Внедрение через конструктор само по себе нормально. Риск — жёсткая зависимость от конкретного B, а в показанном primary constructor this.dependency ещё и не является объявленным полем.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
Класс A получает объект класса B через конструктор и вызывает его метод Bar() внутри собственного метода Foo(). Какие потенциальные проблемы могут возникнуть при такой организации кода?
public class A(B dependency)
{
public void Foo()
{
...
this.dependency.Bar();
...
}
}
Ответ
Внедрение через конструктор само по себе нормально. Риск — жёсткая зависимость от конкретного B, а в показанном primary constructor this.dependency ещё и не является объявленным полем.
В C# 12 параметр первичного конструктора можно использовать как dependency.Bar(), но он не становится публичным/обычным полем с доступом через this. Альтернатива — объявить собственное readonly-поле и сохранить параметр в него. Многоточия в примере также должны быть заменены реальным кодом.
Если B выполняет сеть или обращается к БД, удобнее зависеть от небольшого интерфейса, проверять null и согласовать lifetime. Это позволяет подставить fake в тесте. Интерфейс не нужен автоматически для каждого простого класса: избыточные абстракции тоже усложняют код.