问实体设计原理: Liskov替换原理和依赖反演原理

EN

Liskov的替代原则如下：

类应该与其基类直接替换。

这意味着，如果一个子类扩展了父类，那么它应该是可直接替换的。可以在这里看到的图像

如果你以伯德为例。不是所有的鸟都会飞--但有些会飞。

让我们看一个java示例：

Bird  ostrich = new Ostrich();

如果我要把我的鸵鸟当作一只鸟(是基类/父类)，而且我们在鸟中有功能让鸵鸟飞，尽管它们不应该飞！

这样我们就可以分离出结构：Liskov的重构层次

如果将依赖反转看作一个单独的原则，则会更容易。

如果我们有一个类，就叫一个类。这使得以后很难更改它，而且还需要我们修改源代码。同样，让我们看一个代码示例。

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");
    }
}

在这里，我们传递两个项目(朋友和敌人)的父对象(人)。如果我们通过一个朋友对象，我们将需要一个单独的相同的方法为敌人的方法。我们可以使用开放/封闭原则，有一个单一的方法，可以调用朋友或敌人，或任何未来可能扩展人的方法。依赖反转是将父对象传递出去，而不是创建类的sayHello()方法。这意味着我们所调用的父对象依赖于App，而不是sayHello()来决定要调用哪个对象。

更好的做法是使用依赖反转。只要要传递的类是实现Person的类，那么类greet()调用就不是固定的。

这意味着，应用程序不是依赖朋友。无论是朋友还是敌人，都取决于应用程序。

这样放弃责任意味着我们的代码可以很容易地维护和更改。使用上下文和依赖项注入，配置文件可以确定在引用指定接口时要使用的对象类型。

从某种意义上说，LSP和倾角是对立的。

• LSP控制继承层次结构中的类之间的关系。 (即为父类和子类)。
• DIP管理继承层次结构以外的类之间的关系。 (即不是父类和子类的类)。

为了直观起见，请考虑两个父类和两个子类之间的六种潜在关系。

• LSP关注关系1和2。
  • 只有当Child1和Child2是子类型而不仅仅是子类时，1和2才是正常的。

• DIP与3、4、5和6的关系有关。
  • 3是可以的。
  • 6.禁止。
  • 4和5可以向上，但不能向下。

​

​

替换原则意味着您使用抽象。抽象是好的，因为它们使代码更具有通用性、可重用性和更有价值。例如，如果您的代码使用的是抽象Vehicle，而不是更具体的Car，那么您也可以使用相同的代码，而无需对其他工具(如Bicycle、Truck甚至Ship )进行任何更改，并且它将继续正常工作。当然，要使这个“替代”工作，您必须确保所有Vehicle都遵循相同的约定，这通常意味着它们实现了一个公共接口或扩展了一个公共超类。

依赖注入使代码更好，因为它减少了类之间不必要的联系。这再次使这些类在不同的场景中可重用。例如，如果您的类从文件中获取数据，那么下次您的数据将在数据库中时会遇到问题。你的班级会突然变成一个沼泽，如果-然后-如果-然后-其他的情况下，试图处理不同的事情，这将是一个噩梦来维持。依赖注入使您的类从这个责任中解脱出来--也就是说，您的类只是“需要数据”，调用方有责任确保将数据连接到其中(也称为“注入”)。从技术上讲，依赖注入只是简单地设置一个变量，如myObject.dataSource = databaseDataSource或myObject.dataSource = fileDataSource。