# laravel Contracts
https://laravel.tw/docs/5.3/contracts
https://hackmd.io/@javck/ByJgF8HRP/%2Ffk2R0VczRNScONxEddcCQg

https://blog.csdn.net/VVVinegar/article/details/70759335


**建立 Laravel 的第三方套件時，最好是注入 Laravel contracts 而不是使用 facade，因為套件是建構在 Laravel 外面，無法使用 Laravel 的 facade 測試輔助方法。**

Laravel 的 Contracts 是一組定義了框架核心服務的介面（ interfaces ）。例如，Illuminate\Contracts\Queue\Queue contract 定義了隊列任務所需要的方法，而 Illuminate\Contracts\Mail\Mailer contract 定義了寄送 e-mail 需要的方法。

框架對於每個 contract 都有提供對應的實作，例如，Laravel 提供各種驅動程式的隊列實作，以及由 SwiftMailer 提供的 mailer 實作。

Laravel 所有的 contracts 都放在 各自的 GitHub 儲存庫。除了提供所有可用的 contracts 一個快速的參考，也可以單獨作為一個低耦合的套件讓其他套件開發者使用。

**補充說明:**

合同是等於介面 主要用這個可以更大的擴充
又能一次修改方便
所以她其實等於facad只是實現方法不同

可以把契約想作成你要做某件事情所需具備的條件或執行的動作，所以任何需要做這件事情的實作都必須告訴程式你想怎麼完成這些動作

## Contracts vs php interface
https://stackoverflow.com/questions/34072046/whats-the-difference-between-a-contract-in-laravel-and-an-interface-in-php
契約是一個用於接口的術語，也用於抽像類

## Contracts 與 Facades
Laravel 的 Facades 和幫助函式提供了一種利用 Laravel 服務的簡易做法，無需型別提示並可以從服務容器中解析契約。 在大多數情況下，每個 Facade 都有一個對應的契約(幫助函式也是同樣道理)

和 Facades 不同（它不要求類別的建構子中導入它們），契約允許你為類別定義顯式依賴關係。 一些資深開發者更喜歡以這種顯式方式去定義其依賴關係，所以更喜歡使用契約，而多數開發者則享受 Facade 帶來的便利。總地來說，大部分應用使用 Facades 來進行開發是不會有問題的

**技巧：**

無論您更喜歡 Facades 還是 Contracts，大多數應用都運行得不錯。但是，如果要開發套件的話，則強烈考慮使用 Contracts，因為它們以顯式方式去定義的關係更容易測試

## 個人總結
Facade和Contract只是依赖注入容器的不同使用方式，用Facade就是自己去容器取（把容器当Service Locator用），用Contract就是等容器注入依赖。所以有了门面模式（Facade）和控制反转（Inversion of Control）

###### tags: `Laravel`