为啥要继承一个空接口

刚开始接触队列的时候，看到这里继承了一个空接口，心里一直犯嘀咕，这是什么操作呀

后来问了大神，他是这么说的

• 表示我这里有一个约定的队列规范，虽然是空的，但是有扩展空间（一般升级版本添加新功能），扩不扩展另说。 如果要增加功能，添加规范接口，再让所有实体类实现新增接口，最后打个新版本发布。 这是常见套路。重要的是规范的版本号，不同版本规范有不同功能，实体类怎么实现的不重要（因为你实现了就有那些功能）。

• 写程序的时候，定义一些接口，代表各种功能模块，互相依赖。便于扩展。依赖于接口，只要是实现它的任意对象都可以。写死具体某个对象是比较低级的做法。

• // $app 表示依赖注入容器实例
  $app->get(ShouldQueue::class); // 容器获取这个接口的实体，具体是那个实现它的类的对象，对照关系一般放在配置文件，便于修改调整。理论上，一个框架除了应用开发目录，最好只有配置目录或文件能让人改，这样算好的设计

• 改下配置，就更换了实现类，工厂（依赖注入容器）生产水果（接口），要苹果还是香蕉（实体类），跟工厂约定（调整配置文件：水果 => 苹果）一下即可。

• $container->get(接口名);
  $container->make(接口名, 参数组);
  通过接口名从容器中获取实体对象，具体哪类对象，由配置文件决定。
  比如有个标准输出接口，有两个实体类，一个是标准文件输出，一个是控制台输出。
  你想直接输出控制台，还是输出记录到某个指定文件，由配置文件决定。

  那么，问题来了。既然配置文件决定一个接口对应一个实体类，哪我想用多个实体类怎么办？比如 hyperf 框架，是基于控制台的，如果把控制台输出当作日志，那么还有用户访问请求日志，都是日志，咋办？

• 都是日志，你要根据用户。控制台这块，主要是负责服务器运行，用户日志负责用户访问请求。这个两类，那么可以继承最基础的日志接口，写两个子接口（控制台、用户），根据用途。

• 服务器日志接口、用户访问日志接口，都继承基础日志接口。算是一个细分，比如吃东西，你可以吃饭，也可以吃零食；吃饭可以吃面，或稀饭；吃零食可以吃辣条或薯片。根据需要细分。不需要就没必要。都是吃的，如果只需要决定是正餐还是零嘴，对 $container （依赖注入容器）来说，一个规范接口即可；如果要细分，就要多个。

• 现在常用框架都实现了依赖注入容器，$container->get(接口名)，用接口名，加上配置文件，方便更改实体类。如果写死某个实体类，其实也能改配置（实体类A => 实体类B，这种对应关系的逻辑性和规范性很差）

• 我们定义接口名、类名，方法名、属性名、变量名，这些都要语义化，让人一看就知道大致是做什么用的，最理想的代码是，完全语义化、规范化，没有注释。每个方法/函数都是单一性功能、简洁。
  完美~

本作品采用《CC 协议》，转载必须注明作者和本文链接