Абстракции не должны зависеть от деталей. Подробности должны зависеть от абстракций?

В последние пару дней я довольно много читал о введении/инверсии зависимостей управления/инверсии зависимости. Я думаю, что теперь мое понимание концепции намного лучше. Но я все еще не получаю следующее из википедии:

а. Модули высокого уровня не должны зависят от модулей низкого уровня. И то и другое должен зависеть от абстракций. B. Абстракции не должны зависеть от деталей. Подробности должны зависят от абстракций.

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

Ответ 1

Это означает, что при изменении данных они не должны влиять на абстракцию. Абстракция - это способ, которым клиенты рассматривают объект. То, что происходит внутри объекта, не важно. Например, взять автомобиль, педали, рулевое колесо и рычаг переключения передач - это абстракции того, что происходит внутри двигателя. Они не зависят от деталей, потому что, если кто-то меняет мой старый движок на новый, я все равно должен управлять автомобилем, не зная, что двигатель изменился.

Детали, с другой стороны, ДОЛЖНЫ соответствовать тому, что говорит абстракция. Я бы не хотел использовать двигатель, который внезапно заставит тормоза удвоить скорость автомобиля. Я могу повторно использовать тормоза так, как я хочу, поскольку они внешне ведут себя одинаково.

Ответ 2

Интересный случай, когда абстракция зависит от деталей, - это когда вы определяете интерфейс, который наследуется от IDisposable. Взгляните на следующую абстракцию:

public interface ICustomerRepository : IDisposable
{
    Customer GetById(Guid id);
    Customer[] GetAll();
}

Примечание: IDisposable - это интерфейс, специфичный для .NET, но вы можете легко представить свой интерфейс, содержащий сам метод Dispose вместо наследования от такого интерфейса.

Может показаться удобным для ICustomerRepository реализовать IDisposable. Таким образом, любой вызывающий абонент может распоряжаться репозиторием, и таким образом реализация может реализовать соединение или единицу работы, которые она использует внутри.

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

Ответ 3

Пример абстракции и деталей: поток предоставляет интерфейс для чтения токена. Это абстракция.

Реализация потока потока связана с реализацией интерфейса, определяемого абстракцией: почему это зависит от него. Если он предоставляет другой интерфейс (один для чтения по 100 символов за раз), он не может претендовать на реализацию той же абстракции.

Ответ 4

Подумайте о работе, которую вам нужно вызвать, и о том, как далеко оттуда вы находитесь в настоящее время. Там есть спектр; ваша позиция на нем представляет собой объем работы, который необходимо выполнить для вызова этой функции.

Абстракции перемещают эту позицию ближе к коду, который вы пишете. Например, если вам нужно позвонить в веб-службу, вы можете: 1) написать код вызова непосредственно там, где вам нужно его использовать, или 2) поместить эти данные за абстракцию (например, интерфейс).

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

Это означает, что каждая часть работы может быть абстрагирована так, чтобы она была "ближе" к используемому ей коду. Благодаря тому, что обе стороны операции зависят от абстракций, они становятся понятнее, и ни одна из сторон не должна обладать знаниями о разрыве между ними - это задача абстракции.

Ничего себе, это было абстрактно.