Принцип инверсии зависимости (Dependency Inversion Principle)

Сильная связанность (immobile design)

Теперь давайте взглянем на последний из перечисленных признаков плохого проектирования. Структура считается сильносвязанной, когда интересующие нас части проекта сильно зависят от других ненужных нам деталей.

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

public class EncryptionService
{
    public void Encrypt(string sourceFileName, string targetFileName)
    {
        // Читаем содержимое файла
        byte[] content;
        using(var fs = new FileStream(sourceFileName, FileMode.Open, FileAccess.Read))
        {
            content = new byte[fs.Length];
            fs.Read(content, 0, content.Length);
        }
 
        // шифруем
        byte[] encryptedContent = DoEncryption(content);
 
        // записываем шифрованные данные
        using(var fs = new FileStream(targetFileName, FileMode.CreateNew, FileAccess.ReadWrite))
        {
            fs.Write(encryptedContent, 0, encryptedContent.Length);
        }
    }
 
    private byte[] DoEncryption(byte[] content)
    {
        byte[] encryptedContent = null;
        // здесь находится алгоритм шифрования..
        return encryptedContent;
    }
}

Листинг 1: Служба шифрования, зависящая от деталей

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

Конечно же, мы может сделать наш сервис более гибким, изменив его реализацию. Мы можем использовать конструкцию switch при получении данных и другую switch при отправке зашифрованных данных.

public enum ContentSource { File, Database }
public enum ContentTarget { File, WebService }
 
public class EncryptionService_2
{
    public void Encrypt(ContentSource source, ContentTarget target)
    {
        // Читаем данные
        byte[] content;
        switch (source)
        {
            case ContentSource.File:     content = GetFromFile(); break;
            case ContentSource.Database: content = GetFromDatabase(); break;
        }
 
        // шифруем
        byte[] encryptedContent = DoEncryption(content);
 
        // записываем шифрованные данные
        switch (target)
        {
            case ContentTarget.File:       WriteToFile(encryptedContent); break;
            case ContentTarget.WebService: WriteToWebService(encryptedContent); break;
        }
    }
 
    // остальной код опущен краткости ради
}

Листинг  2: Немного улучшенная служба шифрования

Однако, это только добавляет в систему новые взаимозависимости. С течением времени все больше и больше различных типов источников и приемников данных будут добавляться в эту программу, и в итоге метод Encrypt будет загажен операторами switch/case, и будет зависеть от множества низкоуровневых модулей. Так что в конце концов система потеряет гибкость и станет хрупкой.

На помощь приходит принцип инверсии зависимости.

Почему это называется Инверсией Зависимости?

Структура зависимостей в хорошо спроектированном объектно-ориентированном приложении «инвертирована» по отношению к «традиционной» структуре приложений реализованных в процедурном стиле. В процедурном приложении модули высокого уровня зависят от модулей низкого уровня, а абстракции зависят от деталей (см. листинг 1 и 2).

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

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

А в чем преимущества именно такого подхода, почему именно интерфейсы а не наследования. Есил я правильно понимаю, например в asp.net всюду используеться модель провайдеров и она, если я не ошибаюсь основанна именно на наследовании.

Иногда использую абстрактные классы вместо интерфейсов только потому, что в интерфейсе нельзя объявить делегаты, а в абстрактном классе - можно. Объявлять их в общем пространстве имен мне не очень нравится, а так имя делегата получается как бы в пространстве имени класса, в котором он объявлен. Т.е. получается своеобразная семантическая подсказка о том, что данный делегат предназначен для использования в классах реализующих определенный интерфейс. Я совсем недавно пришел в С#, поэтому может пока не все понимаю..