Тенденция к повышению зависимости

Question

У меня есть вопрос о тенденции, которой я следую, за которой следуют многие разработчики и компании, особенно молодые разработчики или компании, которые начали полагаться на DI в своих разработках. (Признаюсь, я тоже так иногда делаю)

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

1. Я против использования интерфейсов маркеров.
2. Я вижу ограниченное преимущество для интерфейсов, которые имеют одну единственную реализацию.
3. Я не думаю, что есть какое-либо преимущество в зависимости от интерфейсов, а не от жесткой реализации, если каждый раз, когда вы изменяете реализацию, вы собираетесь перекомпилироватьинтерфейс и увеличьте версию.

Единственная причина, по которой они это делают, заключается в том, чтобы извлекать выгоду из инфраструктуры DI для внедрения экземпляров в конструкторы и, возможно, параметров / свойств.но я думаю, что это можно и нужно заменить, зарегистрировав сам класс, а не интерфейс.Ты согласен ?не согласны?Мысли?Исправления?

Answer 1

Если классы зависят от абстракций, а не от реализаций, система слабо связана.Слабое сцепление имеет несколько очень явных преимуществ. Внедрение зависимостей в .NET, второе издание определяет следующие преимущества (глава 1.2.2, таблица 1.1):

• Позднее связывание : службы могут быть замененыс другими службами без перекомпиляции кода.
• Расширяемость : Код можно расширять и использовать повторно способами, не предусмотренными явно.
• Параллельная разработка : Кодможет разрабатываться параллельно.
• ремонтопригодность : классы с четко определенными обязанностями легче обслуживать.
• тестируемость : классы могут тестироваться модульно.

Это не значит, что абстракции всегда полезны.Например, в случае:

• Зависимость находится в том же модуле, что и потребитель.
• Потребитель и зависимость не должны тестироваться независимо.
• Зависимость - это Стабильная зависимость , а не Изменчивая зависимость (см. Главу 1.3.1).
• Зависимость никогда не должна быть Перехвачена.Распространенной причиной перехвата является возможность сквозных задач.

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

Когдау вас есть одна реализация, это обычно означает, что:

• Вы не фальсифицируете зависимость для тестирования
• Вы не перехватываете ее поведение для применения сквозных задач

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

Еще один способ взглянуть на это из Принципа повторного использования абстракций .Наличие системы с множеством однозначных сопоставлений между абстракциями и реализациями - это запах кода.В системах, которые я пишу, у меня обычно есть несколько абстракций, которые реализуются 90% классов в моей системе (эта модель подробно описана в главе 10 DI в .NET ).

Я против использования маркерных интерфейсов.

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

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

Я бы сказал, что это утверждение неверно.Библиотеки DI обычно не заботятся о том, является ли зависимость конкретным типом или абстракцией.Они все равно с радостью делают это для вас.Вы начинаете вводить абстракции из-за преимуществ слабой связи .

Answer 2

Для достижения Принципов SOLID вам нужно строить свое решение на основе абстракции "Интерфейс", когда вы регистрируете интерфейс в контейнере Ioc, вы сохраняете свое решение чистым и связанным только с абстракциями, а не их реализациями, которые могут отличаться вбудущее или необходимость изменений.