设计模式是我摆脱码畜的唯一出路---依赖倒转原则

·  阅读 1232
设计模式是我摆脱码畜的唯一出路---依赖倒转原则

一起养成写作习惯!这是我参与「掘金日新计划 · 4 月更文挑战」的第4天,点击查看活动详情

概念

  • 依赖倒转原则即: 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接口的都可以进行发送了。翻译过来就是说只要你拥有通信的功能我就能使用。

总结

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