まず公式文書における契約の定義を見てみましょう:
Laravel のコントラクトは、フレームワークによって提供されるコア サービスを定義するインターフェイスのセットです。
これは、Laravel のコントラクトがフレームワークによって提供されるコア サービス インターフェイスのコレクションであることを意味します。
言い換えれば、各コントラクトはフレームワークのコアサービスに対応するインターフェースです。
それではどういう意味ですか？公式ウェブサイトの説明も非常にシンプルで、インターフェイスを使用するのは疎結合と簡素化のためです。
最初に大きなアイデアについては話さないで、いくつかの実用的な情報について話して、コントラクトの使用方法を見てみましょう
まず、契約インターフェースのリストを参照します:
コードは次のとおりです:
IlluminateContractsAuthGuard
IlluminateContractsAuthPasswordBroker
イルミネート契約バス配車係
IlluminateContractsCacheRepository
イルミネート契約キャッシュファクトリー
IlluminateContractsConfigRepository
イルミネート契約コンテナコンテナ
IlluminateContractsCookieFactory
IlluminateContractsCookieQueueingFactory
IlluminateContractsEncryptionEncrypter
Illuminate契約ルーティングレジストラ
... 多すぎてこれ以上載せるのが面倒です。公式ウェブサイトのマニュアルに記載されています。 IlluminateContractsRoutingRegistrar コントラクトを例に挙げて説明してみましょう。
まず、app/Providers/AppServiceProvider.php を開き、登録メソッドに注目してください:
コードは次のとおりです:
パブリック関数 register()
{
$this->app->bind(
'IlluminateContractsAuthRegistrar'、
「AppServicesRegistrar」
);
}
$this->app は Application オブジェクトであり、コンテナ オブジェクトでもあります。$this->app->bind メソッドを通じて、IlluminateContractsAuthRegistrar インターフェイスを実装するクラス AppServicesRegistrar をバインドします。
IlluminateContractsAuthRegistrar はコントラクトであることに注意してください。 AppServicesRegistrar このクラス ファイルは app/Services/Registrar.php にあります。
次に、AppHttpControllersAuthAuthController コントローラー クラスを調べて、__construct コンストラクターがあることを確認します。
コードは次のとおりです:
{
$this->auth = $auth;
$this->registrar = $registrar;
$this->ミドルウェア('ゲスト', ['例外' => 'getLogout']);
}
これには 2 つのパラメーターがあり、対応するクラス名前空間はスクリプトの先頭で確認できます。
コードは次のとおりです:
IlluminateContractsAuthGuard を使用します;これらは両方ともコントラクトですが、ここでは Registrar を取り上げます。 $registrar のインターフェイスの種類はパラメーターの種類によってのみ指定されますが、実際に呼び出されるときは、これが依存関係の挿入機能です。 , Laravel は、IlluminateContractsAuthRegistrar インターフェイスを実装するクラスまたはオブジェクトをコンテナ内で自動的に検索し、存在する場合はそれらを取り出して実パラメータとしてコンストラクターに渡します。
使用プロセス全体は、実際には 2 つのステップに要約できます:
コントラクトインターフェースを実装するオブジェクトをコンテナに登録します。
コンストラクターのパラメーターの型はコントラクト インターフェイス クラスとして指定され、フレームワークは条件を満たすオブジェクトを自動的に検索します。
それでは契約のメリットについてお話していきます。
疎結合
公式 Web サイトでは、密結合とは何か、およびコントラクト インターフェイスが疎結合である理由を説明する例が示されています。
まず密結合コードを見てみましょう:
コードは次のとおりです:
クラス リポジトリ {/**
* キャッシュ
*/
保護された $キャッシュ;
/**
* 新しいリポジトリ インスタンスを作成します。
*
* @param SomePackageCacheMemcached $cache
* @return void
*/
パブリック関数 __construct(SomePackageCacheMemcached $cache)
{
$this->cache = $cache;
}
/**
* ID で注文を取得します。
*
* @param int $id
* @return 注文
*/
パブリック関数 find($id)
{
if ($this->cache->has($id))
{
//
}
}
}
コンストラクターに詳細なキャッシュ実装 SomePackageCacheMemcached が注入されていることがわかります。キャッシュサーバーとして Redis を変更したり、API メソッドを変更したりする場合は、プロジェクトが大きい場合は何箇所か変更する必要があります。変更する必要があります。
それでは、Contract インターフェースはこの問題をどのように解決するのでしょうか?コードを参照してください:
コードは次のとおりです:
IlluminateContractsCacheRepository をキャッシュとして使用します;
クラス リポジトリ {
/**
* 新しいリポジトリ インスタンスを作成します。
*
* @param キャッシュ $cache
* @return void
*/
パブリック関数 __construct(Cache $cache)
{
$this->cache = $cache;
}
}
キャッシュ実装にはインターフェイス、つまりコントラクト IlluminateContractsCacheRepository を使用することに注意してください。これは単なるインターフェイスであり、その背後にある memcache であるか redis であるかを気にする必要はないからです。
シンプルさ
すべてのサービスがインターフェース定義を使用すると、サービスに必要な機能が決定しやすくなり、保守や拡張が容易になり、契約インターフェースも読みやすい簡潔な文書とみなすことができます。
