laravel フレームワークのファサード パターン (Facade Pattern) は、サブシステム内の一連のインターフェイスに一貫したインターフェイスを提供するために、サブシステムとの外部通信が統合されたファサード オブジェクトを通じて実行される必要があるというものです。 -level インターフェイス。このインターフェイスにより、このサブシステムが使いやすくなります。アピアランスモードはファサードモードとも呼ばれ、オブジェクト構造モードです。
Laravel で一般的に使用されるものRoute、Redis、Authこれらのファサードは、Laravel で複数の外観クラスが設計され、統一された抽象外観クラスから継承されます。その背後にあるサブシステムにアクセスするための基本的な方法。
新しいビジネス ニーズの場合は、元の外観クラスを変更するのではなく、新しい特定の外観クラスを追加します。同時に、新しい特定の外観クラスは、新しいサブシステム オブジェクトに関連付けられます。そして、外観クラスの目的を置き換えます。
以下は、抽象外観クラスを導入していない単純な外観パターンの例です。Laravel Facade を紹介する記事では、必要に応じて新しいサブシステムを簡単に追加できるように、Laravel が抽象外観クラスを提供していることがわかります。外観クラスを追加し、外観クラスが対応するサブシステム (またはサービス) に正しくプロキシできるようにします。
外観モードには次のロールが含まれています:
ファサード外観ロール
SubSystem サブシステムロール
<?php class Client
{
public function main()
{
(new Facade)->operation();
}
}
class Facade
{
private $systemA;
private $systemB;
public function __construct()
{
$this->systemA = new SystemA;
$this->systemB = new SystemB;
}
public function operation()
{
$this->systemA->operationA();
$this->systemB->operationB();
}
}
class SystemA
{
public function operationA()
{
//
}
}
class SystemB
{
public function operationB()
{
//
}
}「単一責任原則」によれば、ソフトウェアでシステムを複数のサブシステムに分割することは、システム全体の複雑さを軽減するのに役立ちます。共通の設計目標は、サブシステム間の通信と相互依存を最小限に抑えることであり、この目標を達成する 1 つの方法があります。ファサード オブジェクトを導入します。これは、サブシステムにアクセスするためのシンプルで単一のエントリ ポイントを提供します。・外観モードも「デメテルの法則」を体現したもの 新しい外観クラスを導入することで、元のシステムの複雑さを軽減し、クライアントクラスとサブシステムクラスの結合を軽減することができます。 - 外観パターンでは、サブシステムの外部とその内部の間の通信が、統一された外観オブジェクトを通じて実行されることが必要です。外観クラスは、クライアントをサブシステムの内部の複雑さから分離するため、クライアントは外観のみを処理する必要があります。 object without サブシステム内の多くのオブジェクトを操作します。 - アピアランス モードの目的は、システムの複雑さを軽減することです。 - アピアランス モードはクライアントの使用の利便性を大幅に向上させるため、クライアントはサブシステムの動作の詳細を気にする必要がなく、アピアランス ロールを通じて関連する機能を呼び出すことができます。
外観モードの欠点
は、顧客のサブシステム クラスの使用を十分に制限できません。顧客のサブシステム クラスへのアクセスに制限がかかりすぎると、多様性と柔軟性が低下します。
抽象外観クラスを導入しない場合、新しいサブシステムを追加するには、外観クラスまたはクライアントのソース コードの変更が必要になる可能性があり、これは「オープン-クローズ原則」に違反します。
システムには複数の外観クラスがあります
外観パターンでは、通常、必要な外観クラスは 1 つだけであり、この外観クラスはインスタンスを 1 つだけ持ちます。つまり、シングルトン クラスです。多くの場合、システム リソースを節約するために、外観クラスは一般にシングルトン クラスとして設計されます。もちろん、これは、システム全体で 1 つの外観クラスしか存在できないという意味ではありません。システム内で複数の外観クラスを設計し、特定のサブシステムと対話し、対応するビジネス機能をユーザーに提供することができます。
外観クラスを介してサブシステムに新しい動作を追加しようとしないでください。
外観クラスを継承してサブシステムに新しい動作を追加しないでください。このアプローチは間違っています。出現パターンの目的は、サブシステムに新しい動作を追加することではなく、サブシステムに集中化された簡素化された通信チャネルを提供することです。新しい動作の追加は、元のサブシステム クラスを変更するか、新しいサブシステム クラスを追加することによって実現する必要があります。外観クラスを通じて実装されます。
抽象外観クラスの導入
外観モードの最大の欠点は、新しいサブシステムを追加したり、サブシステムを削除したりするときに、外観クラスを変更する必要があることです。特定の時点での外観クラス この問題をある程度解決するために、クライアントは抽象的な外観クラスをプログラムします。新しいビジネス ニーズの場合、元の外観クラスは変更されませんが、新しい特定の外観クラスが新しいサブシステム オブジェクトに関連付けられ、同時に、次の目的を達成するために構成ファイルが変更されます。ソースコードを変更せず、Appearance クラスの目的を置き換えます。
外観パターンでは、サブシステム内の一連のインターフェイスに一貫したインターフェイスを提供するために、サブシステムとの外部通信を統合された外観オブジェクトを通じて実行する必要があります。 、このインターフェイスにより、このサブシステムが使いやすくなります。アピアランスモードはファサードモードとも呼ばれ、オブジェクト構造モードです。
外観モードには 2 つのロールが含まれています。外観ロールは、クライアントで直接呼び出されるロールであり、関連する (1 つ以上の) サブシステムの機能と責任を知ることができます。クライアントから送信されたすべての機能を処理します。受信リクエストは対応するサブシステムに委任され、処理のために対応するサブシステム オブジェクトに渡されます。ソフトウェア システムには同時に 1 つ以上のサブシステムの役割が存在する可能性があります。別のクラスですが、サブシステムの機能を実装するクラスです。
外観パターンでは、サブシステムの外部とその内部の間の通信が統一された外観オブジェクトを通じて実行される必要があるため、外観クラスはクライアントをサブシステムの内部の複雑さから分離するため、クライアントは処理するだけで済みます。外観オブジェクトを使用すると、サブシステム内の多くのオブジェクトを処理する必要がなくなります。
アピアランス モードの主な利点は、サブシステム コンポーネントを顧客から保護し、顧客が処理するオブジェクトの数を減らし、サブシステムを使いやすくすることで、サブシステムと顧客の間の疎結合関係を実現し、大規模なコスト ソフトウェア システムのコンパイル依存性により、異なるプラットフォーム間でのシステムの移植プロセスが簡素化されます。その欠点は、顧客によるサブシステム クラスの使用を十分に制限できず、抽象的な外観を導入せずに新しいサブシステムを追加できることです。クラスの外観クラスまたはクライアントのソース コードを変更する必要がある場合がありますが、これは「オープン-クローズ原則」に違反します。
出現パターンに該当する状況としては、複雑なサブシステムに単純なインターフェイスを提供する場合、階層構造においてクライアント プログラムと複数のサブシステムの間に大きな依存関係がある場合、各層の機能を定義する必要がある場合などがあります。システム 入口は層間の直接接触を防ぎます。
上記がこの記事の全内容です。詳細については、Laravel Framework Getting Started Tutorialを参照してください。
おすすめ関連記事:
Laravelローカル環境構築: Homestead開発環境のデプロイ
おすすめ関連コース:
2017年Laravel最新5本お勧めのビデオチュートリアル
以上がLaravelフレームワークにおける出現パターンの詳細な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
