剛開始接觸佇列的時候，看到這裡繼承了一個空介面，心裡一直犯嘀咕，這是什麼操作呀
後來問了大神，他是這麼說的
表示我這裡有一個約定的佇列規範，雖然是空的，但是有擴充套件空間（一般升級版本新增新功能），擴不擴充套件另說。 如果要增加功能，新增規範介面，再讓所有實體類實現新增介面，最後打個新版本釋出。 這是常見套路。重要的是規範的版本號，不同版本規範有不同功能，實體類怎麼實現的不重要（因為你實現了就有那些功能）。
寫程式的時候，定義一些介面，代表各種功能模組，互相依賴。便於擴充套件。依賴於介面，只要是實現它的任意物件都可以。寫死具體某個物件是比較低階的做法。
// $app 表示依賴注入容器例項
$app->get(ShouldQueue::class); // 容器獲取這個介面的實體，具體是那個實現它的類的物件，對照關係一般放在配置檔案，便於修改調整。理論上，一個框架除了應用開發目錄，最好只有配置目錄或檔案能讓人改，這樣算好的設計改下配置，就更換了實現類，工廠（依賴注入容器）生產水果（介面），要蘋果還是香蕉（實體類），跟工廠約定（調整配置檔案：水果 => 蘋果）一下即可。
$container->get(介面名);
$container->make(介面名, 引數組);
通過介面名從容器中獲取實體物件，具體哪類物件，由配置檔案決定。
比如有個標準輸出介面，有兩個實體類，一個是標準檔案輸出，一個是控制檯輸出。
你想直接輸出控制檯，還是輸出記錄到某個指定檔案，由配置檔案決定。那麼，問題來了。既然配置檔案決定一個介面對應一個實體類，哪我想用多個實體類怎麼辦？比如 hyperf 框架，是基於控制檯的，如果把控制檯輸出當作日誌，那麼還有使用者訪問請求日誌，都是日誌，咋辦？
都是日誌，你要根據使用者。控制檯這塊，主要是負責伺服器執行，使用者日誌負責使用者訪問請求。這個兩類，那麼可以繼承最基礎的日誌介面，寫兩個子介面（控制檯、使用者），根據用途。
伺服器日誌介面、使用者訪問日誌介面，都繼承基礎日誌介面。算是一個細分，比如吃東西，你可以吃飯，也可以吃零食；吃飯可以吃麵，或稀飯；吃零食可以吃辣條或薯片。根據需要細分。不需要就沒必要。都是吃的，如果只需要決定是正餐還是零嘴，對 $container （依賴注入容器）來說，一個規範介面即可；如果要細分，就要多個。
現在常用框架都實現了依賴注入容器，$container->get(介面名)，用介面名，加上配置檔案，方便更改實體類。如果寫死某個實體類，其實也能改配置（實體類A => 實體類B，這種對應關係的邏輯性和規範性很差）
我們定義介面名、類名，方法名、屬性名、變數名，這些都要語義化，讓人一看就知道大致是做什麼用的，最理想的程式碼是，完全語義化、規範化，沒有註釋。每個方法/函式都是單一性功能、簡潔。
完美~
本作品採用《CC 協議》，轉載必須註明作者和本文連結