Получить зависимости от зависимости

Question

Допустим, у меня есть PetManager и Cat :

class PetManager
{
    PetManager(IBusinessLayer businessLayer, IWashingService washingService);

    IBusinessLayer BusinessLayer;

    IWashingService WashingService;
}

class Cat
{
    Cat(PetManager manager, string name, int levelOfStupidity);
}

А теперь давайте скажем, что моей кошке нужна услуга стирки, так ли это, чтобы получить зависимость от моего питомца-менеджера?

class Cat
{
    Cat(PetManager manager, string name, int levelOfStupidity)
    {
        this.manager = manager;
        this.name = name;
        this.levelOfStupidity = levelOfStupidity;
    }

    IWashingService WashingService
    {
        get { return this.manager.WashingService; }
    }
}

Я сильно подозреваю, что да, это было бы ...

Answer 1

Как уже говорилось, Cat - это конкретный класс, поэтому он может раскрывать все, что имеет смысл. Представление аргументов конструктора в качестве свойств только для чтения - совершенно разумная вещь.

Однако, если бы Cat реализовал ICat, я бы сильно подозревал, что показ зависимости, такой как PetManager, через ICat будет негерметичной абстракцией .

По сути, интерфейсы служат своего рода модификатором доступа . Имеет смысл выставлять зависимости от конкретного класса, но не от интерфейса. Зависимости вводятся через конструктор, поэтому никогда не могут быть частью интерфейса - сигнатура конструктора - это наша степень свободы.

Answer 2

Что ж, если вы подписываетесь на инверсию стиля управления / внедрения зависимостей (и кажется, что это так), вы должны подумать о компромиссах.

Полагаю, что несгибаемые люди могут сказать, что вы могли бы получить от этого некоторые проблемы с обслуживанием. Они, конечно, не кажутся брезгливыми из-за того, что у них есть тонны параметров. Так, например, если вы использовали PetManager на 10 различных видах домашних животных, и одному из этих десяти домашних животных потребовалась какая-то специальная функциональность, которая заставила PetManager измениться, вы могли бы повлиять на другие 9 классов, которые зависят от PetManager, и поэтому было бы лучше просто вводить зависимости индивидуально.

Быть прагматичным, хотя ... То, что вы делаете, это абстрагирование множества связанных зависимостей в другой класс и просто передача их как способ группировки и, возможно, упрощения конструирования объектов. Я в порядке с этим. Мне даже это нравится.

Полное раскрытие, хотя: я не такой твердый об этом, как некоторые другие люди. Я вполне могу быть еретиком, но меньше параметров выглядит и пахнет для меня чище. У меня есть это ноющее чувство, что если спросить меня снова через пять лет, я могу почувствовать себя по-другому, но сейчас я нахожусь там.

Answer 3

Я думаю, что единственная проблема в том, что кошка зависит от конкретного Petmanager, если вы абстрагируете PetManager как услугу, способную предоставить услуги стирки , для меня это звучит лучше.

Answer 4

Я думаю, это зависит.Часто, когда вы обнаруживаете, что у вас есть класс SomethingManager, вы просто группируете логику в один класс, а не разбиваете его на составляющие зависимости.В вашей ситуации кажется, что на самом деле у вас вообще не должно быть класса PetManager, а вместо этого нужно вводить зависимости для ваших WashingService и BusinessLayer объектов напрямую.