工場の設計パターンとコードパターン特徴的な構造

ソフトウェア設計パターンの分野では、開発者のための専門家の設計経験を使用しての効果的な方法を提供します。カプセル化、継承、ポリモーフィズム：オブジェクト指向プログラミング言語の重要な機能を使用してデザインモード。

この記事では、工場出荷時のモードを詳細に説明しました。

まず、デザインパターンの分類は、
全体的な三つのカテゴリーにパターンを設計します。

Factory Methodパターン、Abstract Factoryパターン、シングルトン、Builderパターン、プロトタイプモデル：スキーマ、5つのカテゴリーの合計を作成します。

構造モデル、7種類の合計：アダプタモード、装飾的なモード、プロキシモード、外観モード、ブリッジモード、組み合わせモード、フライ級。

行動パターン、11種類の合計：Strategyパターン、モードを説明するためのテンプレートメソッドパターン、オブザーバーモード、イテレータパターン、責任のチェーン・モード、コマンドモード、メモモード状態モード、ビジターパターン、仲介モデル。

また2がある：同時実行パターンとスレッドプールモード。

第二に、一般的な原則とデザインパターンの6つの原則
一般原則：

オープンクローズ原理（オープンクローズ原理）
開口部と拡張のために開かれている原理を閉じますが、変更のため閉鎖。プログラムを展開する必要がある場合、元のコードを変更しますが、ホットスワップ可能なの効果を達成するために、既存のコードを拡張しません。プログラムスケーラビリティを作るためには、メンテナンスとアップグレードの容易さ：だから、一つの文章にまとめました。この効果を達成したい、我々はなど、インターフェースや抽象クラスを使用する必要があり、詳細設計に従ってください、私たちは、この点に言及します。

6つの原則

　　1.シングル責任原則：、彼らはクラスを分割する必要があり、各クラスはそれを失敗し、単一の責任を実装する必要があることを意味変化に複数のクラスのリードは、存在しない理由。

　　2、置換原則リヒター（リスコフの置換原則）リヒター置換原則としてその場所に任意の基底クラスが表示されることができ、サブクラスが表示されることができるようになります。

　　特定に依存しない抽象に依存指向プログラミング・インターフェース、3.依存性逆転原理（依存性逆転原理）これは開閉、特定のコンテンツの原理に基づいています。

　　4、インターフェイス分離原則（インタフェース分掌の原則）の原則があることを意味：サブクラスが実装しなければならないが、それ以外ならば、インタフェースは分割され、各インターフェイスに存在しないよりも少ないです。

　　5、であるデメテルの法則（少なくとも既知の原則）（デメテル原理）：自分の依存度のクラスは、より良いクラスを知っています。つまり、どんなに複雑な依存クラス、ロジックは、パッケージ方法の内部でなければなりません。

　　6、原理（複合リユース原理）原理を多重合成は、合成ポリマー先/代わりの継承の最初の使用です。

第三に、工場出荷時のパターン

工場出荷時のパターンは、スキーマ作成に属し、三つのカテゴリー、簡単なファクトリパターン、Factory Methodパターン、Abstract Factoryパターンに分けることができます

シナリオ：

ここでの唯一のアプリケーションシーンAbstract Factoryパターンを説明するために：オブジェクトはあなたが相互にまたは相互に依存する製品ファミリ時間のシリーズを作成する必要があるときは、Abstract Factoryパターンを使用することができます。より明らか点（すなわち、抽象クラスが複数ある）が複数存在する場合、継承階層、階層であり、階層構造に属し、その一部に関連するそれぞれの実装クラスまたは制約の間に存在する前記あなたは、Abstract Factoryパターンを使用することができます。相関は、製品を作成するために、別の工場の複数を用いて、種々の制約や実装クラス階層との間に存在しない場合、それはより適切です。

1、簡単なファクトリパターンは、その主な機能は、適切な製品を作成するファクトリクラスで判断をする必要があります。新製品を追加するとき、我々はファクトリクラスを変更する必要があります。例えば、理解し、やや抽象的。メーカーのプロセッサコアの生産は、プロセッサコアの2種類を生成することができる唯一の工場を持っている、があります。お客様は、当社が明示的に製造工場を伝える必要があり、プロセッサコアの種類を必要とします。一つの実装は以下のとおりです。

シンプルなファクトリパターンのUMLダイアグラム：

コード：

列挙CTYPE {コリア、COREB}。     
クラスSingleCore    
{    
公共：    
     仮想 無効ショー（）= 0 ;  
}。    
// 单核A     
クラス SingleCoreA：公共SingleCore    
{    
公共：    
     無効ショー（）{coutの<< " SingleCore A " << てendl; }    
}。    
// 単球B     
クラス SingleCoreB：公共SingleCORE    
{    
公共：    
     無効ショー（）{coutの<< " SingleCore B " << てendl; }    
}。    
// 唯一の工場は、裁判官の中に、プロセッサコアの2種類を生成することができ     
、クラスファクトリーさん    
{    
公共：     
    SingleCore * CreateSingleCore（列挙CTYPE CTYPE）    
    {    
        IF（CTYPE ==・コリア）// 植物の分析内の     
            リターン 新しい新 SingleCoreA（）; //は核Aを生成し     
        、他の IF（CTYPE == COREB）    
             を返す 新しい新 SingleCoreB（）; //は核B生み出す     
        他の    
            リターンNULLを。    
    }    
}。

主な欠点：あなたは新しい核タイプを追加したいとき、我々はファクトリクラスを変更する必要があります。ソフトウェアエンティティ（クラス、モジュール、関数）を拡張することができますが、変更することはできません。これは、オープンクローズドの原則に違反します。

2、ファクトリメソッドパターンは、インタフェース定義オブジェクトを作成するための手段は、そうクラスのサブクラスのどのインスタンスを決めます。ファクトリメソッドは、そのサブクラスを遅らせるために、クラスのインスタンスを作成します。それは非常に抽象的に聞こえる、または例では、単に説明しました。工場出荷時にはシングルコアAモデルの生産に専念しながら、自宅でプロセッサー・コア容量のこの生産、たくさんのお金は、そう、Bのシングルコアモデルの生産に特化工場設立することを決定します。このとき、顧客がしなければならないことにする工場を見つけるために、核Aをモデル化するために、例えば、優れた工場を見つけないで、それ以外の場合はB工場を見つけるために、植物の特定のプロセッサコアの種類を言われることはもはや必要性を。

図UMLファクトリメソッド：

クラスSingleCore    
{    
公共：    
     仮想 無効ショー（）= 0 ;  
}。    
// 单核A     
クラス SingleCoreA：公共SingleCore    
{    
公共：    
     無効ショー（）{coutの<< " SingleCore A " << てendl; }    
}。    
// 単球B     
クラス SingleCoreB：公共SingleCORE    
{    
公共：    
     無効ショー（）{coutの<< " SingleCore B " << てendl; }    
}。    
クラスファクトリー    
{    
公共：    
     仮想 SingleCore * CreateSingleCore（）= 0 ;  
}。    
// 生産A原子力発電所の     
クラス FactoryA：公共ファクトリーさん    
{    
公共：    
    SingleCoreA * CreateSingleCore（）{ 返す 新しいSingleCoreAを。}    
}。    
// 原子力発電所Bの生産     
クラス：FactoryB 公共ファクトリーさん    
{    
公共：    
    SingleCoreB * CreateSingleCore（）{ 返す 新しいSingleCoreBを。}    
}。

ファクトリメソッドパターンの欠点：追加の各製品は、我々はファクトリオブジェクトを追加する必要があります。同社は急速に発展した場合、多くの新しいプロセッサ・コアの導入は、それは、対応する新工場をオープンします。C ++の実装では、ファクトリクラスのいずれかを定義することです。もちろん、簡単な工場出荷時のパターンに比べて、ファクトリメソッドは、より多くのクラス定義が必要です。

3、Abstract Factoryパターンは、たとえば、同社の技術は、シングルコアプロセッサを生成することができ、マルチコアプロセッサを作ることができるだけでなく、進歩し続けています。すべての届かない今、単純なファクトリパターンとファクトリメソッドパターン。Abstract Factoryパターンデビュー。それらの具体的なクラスを指定せずにインターフェイスを作成するために、関連する、または従属オブジェクトの列として定義されます。別の植物は、単芯タイプBのマルチコアプロセッサを生成するように設計しながら具体的に、このアプリケーションは、それは、まだ特別なタイプAシングルコアマルチコアプロセッサの製造のための開いた両工場です。

Abstract FactoryパターンのUMLダイアグラム：

以下のコードは、実装を与えられています。

// 単核     
クラスSingleCORE     
{    
公共：    
     仮想 無効ショー（）= 0 ;  
}。    
クラス SingleCoreA：公共SingleCore      
{    
公共：    
     無効ショー（）{coutの<< " シングルコアA " << てendl; }    
}。    
クラス SingleCoreB：公共SingleCore    
{    
public:    
    void Show() { cout<<"Single Core B"<<endl; }    
};    
//多核    
class MultiCore      
{    
public:    
    virtual void Show() = 0;  
};    
class MultiCoreA : public MultiCore      
{    
public:    
    void Show() { cout<<"Multi Core A"<<endl; }    
    
};    
class MultiCoreB : public MultiCore      
{    
public:    
    void Show() { cout<<"Multi Core B"<<endl; }    
};    
//工厂    
class CoreFactory      
{    
public:    
    virtual SingleCore* CreateSingleCore() = 0;  
    virtual MultiCore* CreateMultiCore() = 0;  
};    
//工厂A，专门用来生产A型号的处理器    
class FactoryA :public CoreFactory    
{    
public:    
    SingleCore* CreateSingleCore() { return new SingleCoreA(); }    
    MultiCore* CreateMultiCore() { return new MultiCoreA(); }    
};    
//工厂B，专门用来生产B型号的处理器    
class FactoryB : public CoreFactory    
{    
public:    
    SingleCore* CreateSingleCore() { return new SingleCoreB(); }    
    MultiCore* CreateMultiCore() { return new MultiCoreB(); }    
};

抽象工厂模式中的多台机制：通过父类的虚函数实现动态联编。

抽象工厂模式的优点：

抽象工厂模式除了具有工厂方法模式的优点外，最主要的优点就是可以在类的内部对产品族进行约束。所谓的产品族，一般或多或少的都存在一定的关联，抽象工厂模式就可以在类内部对产品族的关联关系进行定义和描述，而不必专门引入一个新的类来进行管理。

抽象工厂模式的缺点：

产品族的扩展将是一件十分费力的事情，假如产品族中需要增加一个新的产品，则几乎所有的工厂类都需要进行修改。所以使用抽象工厂模式时，对产品等级结构的划分是非常重要的。

至此，工厂模式介绍完了。

代码地址：https://github.com/Jonahmoon/SoftwareEngineering.git

工場の設計パターンとコードパターン特徴的な構造

おすすめ