概念

• 依赖倒转原则即： Dependence Inversion Principle

  • 高层模块不应该依赖底层模块，二者都应该依赖其抽象；我们可以依赖抽象类也可以依赖接口，但是不要依赖具体的子类或者实现类
  • 抽象不应该依赖细节，细节应该依赖抽象
  • 依赖倒转的中心思想是面向接口编程
  • 实际开发中接口或者抽象类基本是固定的，业务的变动只会带来实现类或者子类的改动。上层基本上或者说很少会有改动的。依赖倒转就是基于此，依赖抽象类而不是具体子类或实现类
  • 基于接口或者抽象类完成整体框架的设计，不涉及具体的业务逻辑。实现细节的事情交由子类或者实现类完成

需求

• 现在我们实现一个用户接受邮件的功能。这个功能很简单我们只需要实现一个用户类依赖邮件类即可。用户接受的功能交由邮件来完成

无设计

 public class DependencyInversion {
     public static void main(String[] args) {
         Person person = new Person();
         person.recevice(new Email());
     }
 }
 ​
 class Email {
     public String getInfo() {
         return "电邮";
     }
 }
 ​
 class Person{
     public void recevice(Email email) {
         System.out.println(email.getInfo());
     }
 }

• 上述代码很容易就实现了。也很容易读懂。但是当我们需求增加后就会发现我们的代码改动比较大。
• 后续只要我们增加一种消息类型，就对应的需要增加一个消息实体进行处理，Person类也需要增加相应的方法依赖具体的消息实体来完成消息的接收。

设计

• 仔细想想对于Person来说根本不需要针对每个消息实体进行处理。因为消息实体对于Person来说就是一个载体。Person只需要一个能够发送消息的载体即可，不管你是邮件，微信还是其他通讯工具。而这些工具都有一个特征就是通讯。所以我们需要将其进行抽象。

 public class DependencyInversion {
     public static void main(String[] args) {
         Person person = new Person();
         person.recevice(new Email());
     }
 }
 ​
 interface IReceiver{
     public String getInfo();
 }
 class Email implements IReceiver{
     @Override
     public String getInfo() {
         return "电邮";
     }
 }
 ​
 class Person{
     public void recevice(IReceiver receiver) {
         System.out.println(receiver.getInfo());
     }
 }

• 这样设计Person就不会强依赖Email了，只要是实现了IReceiver接口的都可以进行发送了。翻译过来就是说只要你拥有通信的功能我就能使用。

总结

• 在协作开发时尽量将我们依赖的对象进行抽象化。这里的抽象可以时抽象类也可以时接口。这样方便我们传递子类或者是实现类来进行功能的扩展。
• 在使用变量时也应该尽量来使用抽象类或者时接口。这样我们实际的对象就是一个动态的变量。也方便我们后期对他进行功能的扩展。
• 另外继承时需要注意遵循里氏替换原则。至于啥事里氏替换原则了？关注我不走丢。咱们下期见