デザインパターン - Facadeパターンのクイックガイド

ステップ1 – キーワード

キーワードの定義は、このクイックガイドのシリーズにおける秘伝のレシピである。この方法は、デザインパターンを本当に理解し、それらを頭の中でハードコードし、他のデザインパターン間の違いを理解するのに役立ちました。これは、このデザインパターンの目標です。複雑なシステムを単純化する。

制約。単純化には、しばしば「神聖なコスト」である制限が伴います。コードを単純化することで、クライアントが不正にアクセスできないように制限するのです。したがって、複雑なサブシステムでは感知しにくいようなミスをすることを防ぎます。

単純化と制限の間にはトレードオフがあります。システムを単純化しすぎると、開発者が過剰に制限されることになり、したがって、必要以上に自由度が低くなり、必ずしも良いこととは言えません。一方、Facadeパターンを単純化しすぎると、自由度が高くなりすぎて、Facadeパターンが意味をなさなくなる。

Step 2 – Diagram

この図も与えられた例に基づいて作成されたものです。この図を単純化するために、3つの部分に分けることができます。

Client。この例でのクライアントは、料理を注文したいレストランの顧客です。
Facade。その仕事は、クライアントに、複雑とみなされる多数の相互依存的なサブシステムへのアクセスをより簡略化して提供できるようにすることです。この例では、クライアントの食べ物注文は、2つの異なるサブシステム（ウェイターとキッチン）の一連の注意深く配列されたメソッド呼び出しを必要とします。サブシステム: サブシステムはクライアントから隠されている。また、クライアントからアクセスできない場合もある。クライアントは、単純なコード変更が致命的であることが判明したり、システム自体の他の未知の部分を壊すかもしれないサブシステムのいずれかをいじることはできません。このシナリオでは、ウェイターとキッチンは一連の作業を行わなければならない。あるサブシステムのタスクは、他のタスクに依存することがあります。例えば、ウェイターが注文をキッチンに持ってこなければ、キッチンは料理を準備することができません。

Step 3 – コード例

私の git リポジトリ “Andreas Poyias” からクラスごとのコードまたは以下のスニペットをコピーし (提供された順に)、それを c++shell, jdoodle, onlineGDB など利用できるオンライン C++ エディターに貼り付けて実行し、出力を観察することをお勧めします。その後、以下のコメントや説明を読んでください。

サブシステム

この例では、2つのサブシステムが Waiter_Subsystem1 と Kitchen_Subsystem2 になっています。一見すると、それぞれのサブシステムは個別に特定の作業を行うことができるため、独立しているように見えます。しかし、これは本当でしょうか。

#include <iostream>
using namespace std;class Waiter_Subsystem1
{
public:
void writeOrder() { cout << " Waiter writes client's order\n";}
void sendToKitchen(){ cout << " Send order to kitchen\n";}
void serveCustomer(){ cout << " Yeeei customer is served!!!\n";}
};class Kitchen_Subsystem2
{
public:
void prepareFood(){ cout << " Cook food\n";}
void callWaiter() { cout << " Call Waiter\n";}
void washDishes() { cout << " Wash the dishes\n";}
};

Facade: この例では、Facadeクラスは、レストランでの食品注文に関するものです。食品注文を正常に実行するには、特定のメソッド呼び出しのシーケンスに依存し、1 つの呼び出しは前のものに依存します。ウェイターが注文を書き、それを厨房に送らなければ、厨房は料理を用意することができない。

class Order_Facade
{
private:
Waiter_Subsystem1waiter;
Kitchen_Subsystem2 kitchen;
public:
void orderFood()
{
cout << "A series of interdependent calls on various subsystems:\n";
waiter.writeOrder();
waiter.sendToKitchen();
kitchen.prepareFood();
kitchen.callWaiter();
waiter.serveCustomer();
kitchen.washDishes();
}
};

Main function
main functionはクライアントとして動作する（前のガイドと同じです）。

int main(int argc, char *argv)
{
// Simple for the client 
// no need to know the order or the 
// dependencies among various subsystems.
Order_Facade facade;
facade.orderFood();return 0;
}// Output
// A series of interdependent calls on various subsystems:
// Waiter writes client's order
// Send order to kitchen
// Cook food
// Call Waiter
// Yeeei customer is served!!!
// Wash the dishes

Facade パターンの使用にはいくつかの利点があり、Facade にアプローチする際に注意すべき点があります。

Facade は、複雑なサブシステムをラップして、サブシステムを使いやすくする上位のインターフェースを定義しています。
これにより、サブシステムをうまく活用するために必要な学習曲線が減少します。
また、潜在的に多くのクライアントからサブシステムをデカップリングすることを促進します。
一方で、Facade がサブシステムの唯一のアクセスポイントである場合、「パワーユーザー」が必要とする機能や柔軟性が制限されます。
次のブログは Observer デザインパターンへの簡易ガイドとなります。これは、あなたの知識リポジトリになくてはならない行動パターンです。このブログの投稿に「いいね！」や「拍手」をしたり、私のアカウントをフォローするのを忘れないでください。これは、私が仲間の開発者を助けたという満足感を与え、書き続けることを後押ししてくれるものです。

Design Patterns – A quick guide to Abstract Factory.
Design Patterns – A quick guide to Bridge Pattern.もしあなたが特定のデザインパターンについて学びたいのであれば、私に知らせてください。
Design Patterns – Builder Patternのクイックガイド.
Design Patterns – Decorator Patternのクイックガイド.
Design Patterns – Facade Patternのクイックガイド.
Design Patterns – Observer Patternのクイックガイド.
Design Patterns – Singleton Patternのクイックガイド.

デザインパターン – Facadeパターンのクイックガイド

コメントを残すコメントをキャンセル

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル