Принципы разработки SOLID: принцип замещения Лискова и принцип обращения зависимостей - PullRequest
Новая
       23

Принципы разработки SOLID: принцип замещения Лискова и принцип обращения зависимостей

0 голосов
/ 09 октября 2019

Просто мысль и вопрос к Stack Overflow и сообществу разработчиков Microsoft о принципах разработки программного обеспечения OO под названием SOLID. В чем разница между принципом замещения Лискова и принципом инверсии зависимости? Я думал об этом некоторое время, и я не уверен в разнице. Пожалуйста, не могли бы вы дать мне знать? Любые мысли / отзывы очень приветствуются. Большое спасибо и наилучшие пожелания, Тахер Хассан

1 Ответ

3 голосов
/ 09 октября 2019

Принцип подстановки Лискова гласит следующее:

Класс должен быть напрямую заменен своим базовым классом

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

Если вы посмотрите, возьмите, например, Птица . Не все птицы летают, но некоторые летают.

Давайте рассмотрим пример java: 

Bird  ostrich = new Ostrich();

Если я собираюсь относиться к своему страусу как к птице (это базовый / родительский класс),и у нас есть функциональность в Bird для того, чтобы этот страус летел, хотя они не должны!

Так что мы можем выделить структуру: Рефакторированная иерархия для Лискова

Инверсия зависимости проще, если рассматривать ее как отдельный принцип.

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

public class App {
    public static void main(String[] args) {
        Greeting greeting = new Greeting();
        greeting.sayHello(new Friend()); 
        greeting.sayHello(new Enemy());
    }
}

public class Greeting {
    public void sayHello(Person person) {
         person.greet();
    }
}

public interface Person {
    public void greet();
}

public class Friend implements Person {
    public void greet() {
        System.out.println("Hello my friend");
    }
}

public class Enemy implements Person {
    public void greet() {
        System.out.println("Go away");
    }
}

Здесь мы передаем родительский объект (Person) обоих элементов (Friend и Enemy). Если бы мы прошли через объект Friend, нам понадобился бы отдельный идентичный метод для метода Enemy. Мы можем использовать принцип Open / Closed, чтобы иметь единственный метод, который может вызывать Friend или Enemy или что-нибудь в будущем, что может расширить Person. Инверсия зависимостей заключается в том, что вместо метода sayHello (), создающего класс, передается родительский объект. Это означает, что родительский объект, который мы вызываем, зависит от App, а не от sayHello (), определяющего, какой объект вызывать.

Лучше использовать инверсию зависимостей. Вызовы класса greet () не установлены в камне, поскольку передаваемый класс является тем, который реализует Person.

Что это означает, что вместо того, чтобы App зависеть от Friend. Вопрос о том, будет ли вызван друг или враг, зависит от приложения.

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

...