C++デザインモードの外観モード

前言
実際に開発する時、1つの大きいシステムに直面して、いつも1つの大きいシステムをいくつかのサブシステムに分けて、サブシステムが完成した後に、更にそれぞれ対応するサブシステムを呼び出して対応する全体の機能を完成して、このようにシステムの複雑性を下げるのに有利です;最終的に特定の機能を実現する場合、対応するサブシステムを組み合わせるとよい.しかし,サブシステムがそんなに多く,関係がそんなに複雑で,完全なシステムを組み合わせて形成することは困難である.
私たちがvisual studioを使用してC++コードをコンパイルするとき、あなたはメニューの中でBuildを選択しただけで、visual studioは多くのコンパイル作業を開始しました.あなたの簡単なBuild動作のため、コンパイラはバックグラウンドで文法分析を行い、中間コードを生成し、アセンブリコードを生成し、実行可能なプログラムやライブラリにリンクするなどの動作を行うことを知っておく必要があります.このすべては、プログラムを開発している私たちとして、コンパイラが何をしているのかを理解する必要はありません.コンパイラは私たちに背後にある複雑な操作を隠しています.Buildボタンは1つしか提供されていません.このBuildボタンは、すべての操作を実行することができます.このBuildボタンをクリックすると、Buildは背後で、異なるサブシステムにタスクを配布して完了し、最終的にサブシステムが協力してコンパイルタスク全体を完了します.このように複雑な操作を隠して、より高いレベルの統一インタフェースを提供するだけで、私が今日まとめた外観モードです.
外観モードとは?
外観モードは、多くの人がそれをフェースモードと呼んでいます.GOFの「設計モード:多重化可能なオブジェクト向けソフトウェアの基礎」という本では、サブシステムのインタフェースのセットに一貫したインタフェースを提供し、外観モードは高レベルのインタフェースを定義し、このインタフェースはこのサブシステムをより使いやすくしている.この言葉を細かく理解する.サブシステムのインタフェースのセットは、上記の例の文法分析のように、中間コードを生成し、アセンブリコードを生成し、実行可能なプログラムまたはライブラリにリンクする.外観モード定義の上位インタフェースは、前述のBuildボタンのように、このようなBuildボタンによってコンパイラがより使いやすくなる点で、Linux C++/CからWindows C+/Cに移行するプログラマーが最も体得しています.Visual studioが提供する強力な機能は、Buildボタン1つでmakefileファイルを書く必要がなく、Build動作を行うことができ、いくつかのコマンドを実行してコンパイルすることができます.
UMLクラス図
Facade:どのサブシステムクラスが要求を処理し、顧客の要求を適切なサブシステムオブジェクトにエージェントするかを知っています.
SubSystem:サブシステムの具体的な機能を実現する;Facadeオブジェクトによって割り当てられたタスクを処理します.しかし、SubSystemにはFacadeに関する情報は一切ありません.つまり、Facadeへのポインタはありません.
Clientは、サブシステムと直接関係なくFacadeに要求を送信することによってサブシステムと通信し、Facadeはこれらのメッセージを適切なサブシステムオブジェクトに転送する.サブシステム内の関連オブジェクトが実際に働いているにもかかわらず、Facadeモード自体もそのインタフェースをサブシステムのインタフェースに変換しなければならないので、ここでは少しアダプタモードの感じがしますか?これが構造型の設計パターンを学ぶ感覚で、感覚は似ていますが、よく研究すると、それぞれの役に立つことがわかります.
コード実装
ここで実装するコードは,私が上に挙げたコンパイラの例を参照する.

/*
** FileName     : FacadePatternDemo
** Author       : Jelly Young
** Date         : 2014/1/2
** Description  : More information, please go to http://www.jellythink.com
*/

#include 
using namespace std;

//        
class CSyntaxParser
{
public:
     void SyntaxParser()
     {
          cout<<"Syntax Parser"<<endl;
     }
};

//          
class CGenMidCode
{
public:
     void GenMidCode()
     {
          cout<<"Generate middle code"<<endl;
     }
};

//          
class CGenAssemblyCode
{
public:
     void GenAssemblyCode()
     {
          cout<<"Generate assembly code"<<endl;
     }
};

//                 
class CLinkSystem
{
public:
     void LinkSystem()
     {
          cout<<"Link System"<<endl;
     }
};

class Facade
{
public:
     void Compile()
     {
          CSyntaxParser syntaxParser;
          CGenMidCode genMidCode;
          CGenAssemblyCode genAssemblyCode;
          CLinkSystem linkSystem;
          syntaxParser.SyntaxParser();
          genMidCode.GenMidCode();
          genAssemblyCode.GenAssemblyCode();
          linkSystem.LinkSystem();
     }
};

//    
int main()
{
     Facade facade;
     facade.Compile();
}

上のコードは簡単です.外観モードを使用していない場合、クライアントがCompileと同じ動作を行う場合、Compileと同じコードを書く必要があることを想像することができます.はい、話せるから、書いてください.しかし、クライアントはサブシステム間の関係をあまり熟知していない場合があります.例えば、文法分析を行い、中間コードを生成し、アセンブリ言語を生成し、最後にリンクを行うのと同じです.クライアントがこのタイミングを知らない場合は、どうすればいいですか?だから、外観モードはすべての複雑なものを、使用するのが簡単になりました.
メリット

それは顧客に対してサブシステムコンポーネントを遮断したので、顧客が処理するオブジェクトの数を減らし、サブシステムの使用をより便利にした.

それはサブシステムと顧客との間の緩やかな結合関係を実現し、サブシステム内部の機能コンポーネントは往々にして緊密に結合されている.松結合システムは、サブシステムのコンポーネントの変化が顧客に影響を与えないようにします.外観モードは、階層システムの構築に役立ち、オブジェクト間の依存関係の階層化にも役立ちます.外観モードは、複雑なループ依存関係を解消します.この点は,クライアントプログラムとサブシステムが別々に実現される場合に特に重要である.

使用する場合

複雑なサブシステムに簡単なインタフェースを提供する場合.サブシステムは往々にして進化し続けるためにますます複雑になる.ほとんどのモードでは、より小さなクラスが生成されます.これにより、サブシステムの再利用性が向上し、サブシステムのカスタマイズも容易になりますが、サブシステムのカスタマイズを必要としないユーザーにも使用上の困難をもたらします.外観モードは、ほとんどのユーザーにとって十分であり、よりカスタマイズ性が必要なユーザーはFacadeレイヤを越えることができます.

クライアント・プログラムと抽象クラスの実装部分との間に大きな依存性がある場合.Facadeを導入してこのサブシステムを顧客や他のサブシステムと分離し、サブシステムの独立性と移植性を高めることができる.

階層のサブシステムを構築する必要がある場合、外観モードを使用してサブシステム内の各層のエントリポイントを定義します.サブシステム間が相互に依存している場合,Facadeのみで通信させることができ,それらの依存関係を簡素化することができる.

まとめ
外観モードは簡単で使いやすく、お客様がサブシステムをより簡単に使用できるようにします.他人の文章を拝読する時、以下の総括がとても良くて、私も参考にします.

設計の初期に、意識的に異なる層を分離しなければならない.例えば、よく使われる3層アーキテクチャは、データアクセス層と業務論理層表現層との間にFacadeを構築し、複雑なサブシステムに簡単なインタフェースを提供し、結合性を低下させることである.

開発段階では、サブシステムは絶えず再構築されるためますます複雑になり、外観Facadeを増加させることで簡単なインタフェースを提供し、それらの間の依存性を減少させることができる.

メンテナンス段階では、このシステムのメンテナンスと拡張が非常に困難になっている可能性があります.この場合、新しいシステムの外観クラスを開発して、粗雑な設計や高度に複雑なレガシーコードの比較的明確で簡単なインタフェースを提供し、新しいシステムをFacadeオブジェクトとインタラクティブにし、Facadeとレガシーコードをインタラクティブにするすべての複雑な作業を提供することができます.

通常、サブシステムへのアクセスにはFacadeレイヤを提供しますが、このFacadeエントリは1つしか必要ありません.すなわち,Facadeを使用する場合,Facadeモードを実現するために単一のモードを用いることができる.外観パターンについてはこれでまとめましたが、間違いなく見落としがありますので、ご指摘ください.分かち合いは私たちをもっと進歩させると信じています.
2014年1月2日大連、東軟で.