C++設計モードの抽象工場モード

C++設計モードの抽象工場モード

C設計モデルの抽象工場モデル

一缘由

二実現

三コード分析

四総括

一、缘由
「C++設計モデルの工場方法モデル」では、単純な工場モデルの中の工場類の職責が重すぎるため、単一の職責の原則に深刻に違反し、システムの拡張が非常に困難であるため、工場方法モデルを引き出し、工場方法モデルは抽象的な工場類に導入され、具体的な創建作業は具体的な工場類ごとに延期された.このように、各特定の工場クラスは1つの製品の作成だけを担当し、各特定の工場クラスの職責は十分に単一で、十分に簡単です.ファクトリメソッドモデルの欠点は、クラスの職責が単一すぎて、システムの作成に必要な作業を完了し、製品タイプが増加すると、ファクトリクラスも急激に増加し、システム内のクラスが多すぎることです.どうすればいいの?解決方法は簡単です.特定の工場クラスにより多くの仕事を担当させます.つまり、1つ以上のタイプの特定の製品の作成を担当します.一連の製品の作成を担当します.しかし、ここで問題がまた来ました.このようなモデルと簡単な工場はどんな違いがありますか.また単一職責の原則に違反したのではないか.答え:1.単純ファクトリモードは、1つのファクトリクラスを使用してシステム内のすべての製品クラス行を作成し、抽象ファクトリモードは、1つのファクトリクラスを使用して一連の製品作成を行います.製品携帯電話がノキアNシリーズ:N 97,N 70,N 80であると仮定する.ノキアSシリーズ:6260 s,6500 s,6700 sとノキアE 50,E 61,E 71携帯電話.単純工場は,N 97,N 70,N 806260 s,6500 s,6700 s,E 50,E 61,E 71の工場を用いて作成した.抽象工場モデルはそれぞれ3つの具体的な工場類:NFactory、SFactory、EFactoryを用いて、それぞれNシリーズ、Sシリーズ、Eシリーズの携帯電話を作成した.2.私が「単一職責と里氏置換」で述べたように、職責をどのように区分するかは具体的なシーンでしか具体的な区分ができず、異なる需要の下で、区分は異なる可能性がある.単純工場モデル、工場方法モデル、抽象工場モデルでは、職責の区分は、製品の作成を職責とし、製品の作成を職責とし、一連の製品の作成を職責とし、3つの工場モデルの職責の区分粒度が異なる.どのような場合にどの工場モデルを使うかは、職責の区分が合理的かどうかにかかっている.職責を分けるときは、粒度を大きくしたり、小さくしたりしてはいけません.粒度が大きすぎると、単一のクラスの職責が重すぎて、メンテナンスが難しくなり、粒度が小さすぎるとクラスの数が多すぎて、システムが複雑になります.
二、実現
抽象ファクトリモデルでは、特定のファクトリクラスがより多くの役割を果たし、各特定のファクトリクラスが同じ製品レベルのすべての製品ファミリー製品の作成を担当します.例えば、LINUXとWINDOWSは同じ製品レベルにあり、LINUX PCバージョンとLINUXモバイルバージョンはLINUXという製品レベルの製品ファミリーである.このような抽象ファクトリモードのUMLクラス図を以下に示す.
三、コード分析
サンプルコードは次のとおりです.

#include <iostream>
#include <string>

//      A
class ProductA {
public:
    virtual void whichType() = 0;
    virtual ~ProductA(){}
};
//      B
class ProductB {
public:
    virtual void whichType() = 0;
    virtual ~ProductB(){}    
};
//   1
class ProductA1 : public ProductA {
public:
    virtual void whichType(){std::cout << "ProductA1" << std::endl;}
};
//   2
class ProductA2 : public ProductA {
public:
    virtual void whichType(){std::cout << "ProductA2" << std::endl;}
};
//   1
class ProductB1 : public ProductB {
public:
    virtual void whichType(){std::cout << "ProductB1" << std::endl;}
};
//   2
class ProductB2 : public ProductB {
public:
    virtual void whichType(){std::cout << "ProductB2" << std::endl;}
};

class Factory {
public:
    virtual ProductA *createProductA() = 0;
    virtual ProductB *createProductB() = 0;
    ~Factory(){}
};

class Factory1: public Factory{
public:
    virtual ProductA *createProductA(){return new ProductA1;}
    virtual ProductB *createProductB(){return new ProductB1;}
};

class Factory2: public Factory{
public:
    virtual ProductA *createProductA(){return new ProductA2;}
    virtual ProductB *createProductB(){return new ProductB2;}
};

 int main(void) {
    Factory *factory1 = new Factory1;
    ProductA *typeA1 = factory1->createProductA();
    ProductB *typeB1 = factory1->createProductB();

    Factory *factory2 = new Factory2;
    ProductA *typeA2 = factory2->createProductA();
    ProductB *typeB2 = factory2->createProductB();

    typeA1->whichType();
    typeB1->whichType();
    typeA2->whichType();
    typeB2->whichType();

    return 0;
}

    ：
ProductA1
ProductB1
ProductA2
ProductB2

四、まとめ
メリット:

単一の具体的な工場類が責任を負う職責の適量は、システム中の具体的な工場類の数を減らすのに有利である.

新しい製品ファミリーを追加するのは便利で、既存のシステムを修正する必要はありません.
欠点:

新しい製品の等級構造を増やすのは面倒で、大量のクラスを修正する必要があり、抽象クラスを修正する必要もあり、開閉の原則に反している.

使用シーン:上記の説明から分かるように、製品の等級構造が安定している場合、抽象工場メソッドモードを使用することができる.