Статья:
Управление зависимостями

Автор(ы): Тепляков Сергей Владимирович
Дата: 23.10.2015
Основная суть управления зависимостями, как и любого другого принципа проектирования, сводится к борьбе со сложностью и упрощению сопровождения, и не является самоцелью. Инверсия зависимостей заключается к перекладыванию ответственности на более высокий уровень, но нужно четко понимать, что это не решение проблемы, а изменение ее формы.

Авторы:
Тепляков Сергей Владимирович

Аннотация:
Основная суть управления зависимостями, как и любого другого принципа проектирования, сводится к борьбе со сложностью и упрощению сопровождения, и не является самоцелью. Инверсия зависимостей заключается к перекладыванию ответственности на более высокий уровень, но нужно четко понимать, что это не решение проблемы, а изменение ее формы.

Здравствуйте, Тепляков Сергей Владимирович, Вы писали:

ТСВ>Статья:
ТСВ>Управление зависимостями

Автор(ы): Тепляков Сергей Владимирович
Дата: 23.10.2015
Основная суть управления зависимостями, как и любого другого принципа проектирования, сводится к борьбе со сложностью и упрощению сопровождения, и не является самоцелью. Инверсия зависимостей заключается к перекладыванию ответственности на более высокий уровень, но нужно четко понимать, что это не решение проблемы, а изменение ее формы.

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

Я извиняюсь, а это точно инверсия (Dependency Inversion), а не инжекция (Dependency Injection)?
По моему это хорошее определение инжекции, а инверсия это про зависимости между модулями, когда вместо BL->DL делается BL<-DL путем объявления IDataAccess в BL.

Здравствуйте, AK85, Вы писали:

AK>Я извиняюсь, а это точно инверсия (Dependency Inversion), а не инжекция (Dependency Injection)?
AK>По моему это хорошее определение инжекции, а инверсия это про зависимости между модулями, когда вместо BL->DL делается BL<-DL путем объявления IDataAccess в BL.


DI vs. DIP vs. IoC

Здравствуйте, SergeyT., Вы писали:

ST>Здравствуйте, AK85, Вы писали:

AK>>Я извиняюсь, а это точно инверсия (Dependency Inversion), а не инжекция (Dependency Injection)?
AK>>По моему это хорошее определение инжекции, а инверсия это про зависимости между модулями, когда вместо BL->DL делается BL<-DL путем объявления IDataAccess в BL.


ST>DI vs. DIP vs. IoC

Мне кажется что в своем блоге Вы описываете Dependency Inversion иначе чем в статье на RSDN.

Цитата из блога:

Принцип инверсии зависимости говорит о том, к каким видам зависимостей нужно стремиться. Важно, чтобы зависимости класса были понятны и важны вызывающему коду. Зависимости класса должны располагаться на текущем или более высоком уровне абстракции. Другими словами, не любой класс, который требует интерфейс в конструкторе следует принципу инверсии зависимостей:

class ReportProcessor
{
    private readonly ISocket _socket;
    public ReportProcessor(ISocket socket)
    {
        _socket = socket;
    }
    public void SendReport(Report report, IStringBuilder stringBuilder)
    {
        stringBuilder.AppendFormat(CreateHeader(report));
        stringBuilder.AppendFormat(CreateBody(report));
        stringBuilder.AppendFormat(CreateFooter(report));
        _socket.Connect();
        _socket.Send(ConvertToByteArray(stringBuilder));
    }
}

Класс ReportProcessor все еще принимает «абстракцию» в аргументах конструктора — ISocket, но эта «абстракция» находится на несколько уровней ниже уровня формирования и отправки отчетов. Аналогично дела обстоят и с аргументом метода SendReport: «абстракция» IStringBuilder не соответствует принципу инверсии зависимостей, поскольку оперирует более низкоуровневыми понятиями, чем требуется. На этом уровне нужно оперировать не строками, а отчетами.

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

Сравните с описанием в статье на RSDN:

Суть инверсии зависимостей сводится к тому, что класс перекладывает ответственность за создание зависимости или получение ее экземпляра на более высокий уровень, в результате чего он сам не создает экземпляр конкретного класса, а получает его от более высокоуровневого кода через конструктор или свойство. В результате мы заменяем композицию агрегацией и перекладываем часть проблем с текущего класса куда-то выше.

Здесь Вы говорите что суть в том чтобы переложить ответственность за создание зависимости на внешний код.

Я хотел сказать что есть еще одно толкование принципа Dependency Inversion, получается уже третье. Хорошо изложено в этом ответе на SO.
Там говорится о направлении зависимости между отдельными компонентами. Ключевые слова:

the Dependency Inversion Principle is primarily about reversing the conventional direction of dependencies from "higher level" components to "lower level" components such that "lower level" components are dependent upon the interfaces owned by the "higher level" components.

Вполне может быть, что в блоге Вы именно это и имеете ввиду, хотя и немного расплывчато.
Описание же в статье на RSDN, как по мне, так сильно смахивает на описание Dependency Injection.