определение:
Модули высокого уровня не должны полагаться на модули низкого уровня, оба должны полагаться на их абстракцию; Абстракции не должны полагаться на детали; Детали должны полагаться на абстракцию.
Происхождение проблемы: класс A напрямую зависит от класса B. Если вы хотите изменить класс A, чтобы зависеть от класса C, вы должны достичь его, изменяя код класса A. В этом сценарии класс A, как правило, является модулем высокого уровня, который отвечает за сложную бизнес-логику; Класс B и класс C являются модулями низкого уровня, которые отвечают за базовые атомные операции; Если класс A изменяется, это принесет ненужные риски для программы.
Решение: измените класс A, чтобы зависеть от интерфейса I, а также класса B и класса C Каждый интерфейс реализации I. класс A Косвенно контакты класса B или класс C через интерфейс I, что значительно уменьшит вероятность изменения класса A.
Принцип инверсии зависимости основан на том факте, что абстрактные вещи гораздо более стабильны, чем изменчивость в деталях. Архитектура, построенная на реферате, гораздо более стабильна, чем архитектура, основанная на деталях. В Java Abstract относится к интерфейсу или абстрактному классу, а детали являются конкретными классами реализации. Цель использования интерфейса или абстрактного класса состоит в том, чтобы сформулировать спецификации и контракты без каких -либо конкретных операций и передать задачу представления деталей их классам реализации для завершения.
Основной идеей принципа инверсии зависимости является программирование, ориентированное на интерфейс. Мы все равно будем использовать пример, чтобы проиллюстрировать, где программирование, ориентированное на интерфейс, лучше, чем программирование, ориентированное на реализацию. Сцена такая: мать рассказывает историю своему ребенку. Пока она дает ей книгу, она может рассказать истории своему ребенку в соответствии с книгой.
пример:
Инверсия незаконной зависимости
открытый класс студент {public void Read (Book Book) {System.out.println ("Студент начинает читать:"+book.getName ()); }} public Class Book {public String getName () {return "book"; }}
Когда студенты должны читать веб -страницы, им нужно изменить класс учеников, что является очень недружественным дизайном. Давайте посмотрим на пример соблюдения принципа инверсии зависимости.
Public Interface Person {public void Read (Reader Reader); } public interface Reader {public String getName (); } открытый класс Студент реализует Person {@Override public void Read (Reader Reader) {System.out.println ("Студент начал чтение:"+reader.getName ()); }} открытый класс книга реализует reader {public String getName () {return "book"; }} веб -сайт открытого класса реализует reader {public String getName () {return "веб -страница"; / Student.read (New Book ()); Student.read (новый сайт ()); }}
В методе чтения мы используем интерфейс в качестве параметра.
Суммировать:
1. Лучше всего иметь интерфейсы или абстрактные классы для каждого класса, или как интерфейсы, так и абстрактные классы.
2. Объявление переменной предпочтительно является интерфейсом или абстрактным классом.
3. Сохранять принцип замены во время наследования.