Работа с отношениями и потенциальными несоответствиями с DI / IoC

Question

У меня возникают проблемы при разработке классов, чтобы наилучшим образом использовать принципы DI / IoC, особенно когда класс разделяет зависимость с одной из своих зависимостей (т. Е. X имеет зависимости Y и Z, а Y имеет зависимость Z).

Пример, вероятно, будет полезен:

Допустим, у меня есть класс, который будет инкапсулировать некоторую информацию о соединении для моего приложения. Назовите это «ConnectionInfo»

class ConnectionInfo
{
    // ...
}

Я разработал рабочий класс, который использует информацию о соединении, поэтому я буду вводить свои зависимости через конструктор.

class Worker 
{
    public Worker(ConnectionInfo c) 
    {
        // ...
    }
}

Теперь, допустим, я хочу построить еще один класс. Ему нужен доступ к информации о соединении, но я также хочу получить доступ к функциям, предоставляемым классом Worker.

class AnotherClass
{
    public AnotherClass(ConnectionInfo c, Worker w)
    {
       // ...
    }
}

Это все хорошо. Однако существует подразумеваемая логическая связь между объектом ConnectionInfo, внедренным в Worker, и объектом ConnectionInfo, внедренным в AnotherClass. Дизайн имеет смысл только тогда, когда они одинаковы. Это не принудительно, хотя. Ничто не мешает одному ConnectionInfo, внедренному в AnotherClass, и совершенно не связанному ConnectionInfo, внедренному в Worker.

Я неправильно отношусь к IoC / DI?
Должны ли классы быть разработаны по-другому или проблемы должны решаться по-другому (например, принудительное выполнение с помощью проверки параметров или, может быть, просто оставление его до контейнера IoC)?

Answer 1

Я не думаю, что есть проблема с дизайном класса

, когда вашему клиентскому коду нужен объект AnotherClass, который создаст свои собственные зависимости ConnectonInfo и Worker.

На самом деле существует 2 сценария.

1 - если ConnectionInfo и Worker являются синглетонами: в этом случае, если вы создаете объект AnotherClass, эти же объекты ConnectionInfo и Worker будут совместно использоваться AnotherClass.

2 - Если точка 1 не соответствует действительности: чем каждый раз, когда вы создаете свой AnotehrClass, контейнер будет вводить зависимости как свежие объекты.

Но для ConnectionInfo я могу сказать, что это может быть объект Sigleton, потому чтоэто общая информация, которая нужна вашему приложению, поэтому я бы сказал, что сделать ConectionInfo как Singleton, а остальное в порядке, я не думаю, что вы нарушаете какие-либо правила IoC.