デザインパターン|抽象的なファクトリパターン

1 |抽象ファクトリパターンの概要

1.1基本的な考え方

ファクトリメソッドパターンは、ファクトリ階層を導入することで、単純なファクトリパターンのファクトリクラスの責任が重すぎるという問題を解決します。ただし、ファクトリメソッドパターンの特定のファクトリには、1つまたは一連のオーバーロードされたファクトリメソッドしかないため、この種の製品は、システム内に多数のファクトリをもたらす可能性があり、必然的にシステムのオーバーヘッドが増加します。工場では、単一の製品オブジェクトではなく、複数の製品オブジェクトを提供する必要がある場合があります。たとえば、電気製品工場では、1種類の電気器具だけでなく、テレビ、冷蔵庫、エアコンなどの複数の電気器具を製造できます。。この時点で、いくつかの関連製品を、同じファクトリによって生成される「製品ファミリ」に結合することを検討できます。これは、この章で学習する抽象的なファクトリモデルの基本的な考え方です。

1.2名詞の説明

抽象ファクトリパターンは、一般的に使用される作成デザインパターンの1つであり、ファクトリ（メソッド）パターンよりも抽象度が高くなっています。ファクトリ（メソッド）モードでは、特定の各ファクトリは特定の製品を生産するだけで済みますが、抽象ファクトリモードでは、特定のファクトリは関連する特定の製品のグループを生産できます。このような製品のグループは製品ファミリと呼ばれます。製品ファミリーの製品は、特定の製品継承階層に属しています。

抽象ファクトリパターンを理解する前に、まず次の2つの名詞の概念を理解します。

（1）製品階層構造：製品階層構造は製品の継承構造です。たとえば、抽象カテゴリはTVであり、そのサブカテゴリにはHaier TV、Hisense TV、TCL TV、次に抽象TVと特定のブランドTVAが含まれます。製品レベルの構造がそれらの間に形成されます。抽象的なテレビセットは親カテゴリであり、特定のブランドのテレビセットはそのサブカテゴリです。
（2）製品ファミリ：抽象ファクトリモデルでは、製品ファミリは、同じファクトリによって製造され、異なる製品階層構造に配置されている製品のグループを指します。たとえば、ハイアール電化製品工場で製造されたハイアールTVとハイアール冷蔵庫、ハイアールTVはテレビ製品階層にあり、ハイアール冷蔵庫は冷蔵庫製品階層にあり、ハイアールTVとハイアール冷蔵庫は製品ファミリを形成しています。

1.3抽象ファクトリパターンの定義

抽象ファクトリパターンは、オブジェクトのセットを作成するためのソリューションを提供します。ファクトリモデルと比較すると、抽象ファクトリモデルの特定の職長は、製品を作成するだけでなく、製品のファミリを作成することです。

抽象ファクトリパターン：特定のクラスを指定せずに、一連の関連オブジェクトまたは相互依存オブジェクトを作成するためのインターフェイスを提供します。
抽象ファクトリパターン：具体的なクラスを指定せずに、関連オブジェクトまたは依存オブジェクトのファミリを作成するためのインターフェイスを提供します。

抽象ファクトリパターンは、ツール（Ki）パターンとも呼ばれ、オブジェクト作成パターンです。

2 |抽象ファクトリの構造と実現

2.1
抽象ファクトリパターンの構造抽象ファクトリパターンでは、各コンクリートファクトリが複数のファクトリメソッドを提供してさまざまな種類の製品を生成し、これらの製品が製品ファミリを構成します。
抽象ファクトリパターンには、次の4つの役割が含まれます。

（1）AbstractFactory：製品のファミリーを作成するための一連のメソッドを宣言し、各メソッドは製品に対応します。
（2）ConcreteFactory（コンクリートファクトリ）：抽象ファクトリで製品を宣言および作成する方法を実装し、一連のコンクリート製品を生成します。これらの製品は製品ファミリを構成し、各製品は特定の製品階層に配置されます。
（3）AbstractProduct（抽象製品）：各製品のインターフェースを宣言し、抽象製品内の製品のビジネスメソッドを宣言します。
（4）ConcreteProduct（コンクリート製品）：コンクリート工場で生産されるコンクリート製品オブジェクトを定義し、抽象製品インターフェースで宣言されたビジネスメソッドを実現します。

2.2抽象ファクトリパターンの実装
抽象ファクトリでは、さまざまなタイプの製品を作成するために複数のファクトリメソッドが宣言されています。抽象ファクトリは、インターフェイス、抽象クラス、または具象クラスにすることができます。典型的なコードは次のとおりです。
アプリケーションの例、企業は一連のスキンライブラリ、インターフェイスを美化するための.NETプラットフォームに基づくデスクトップソフトウェアを開発したいと考えています。

コードデザイン：

インターフェイスISkinFactoryは抽象ファクトリとして機能し、そのサブクラスSpringSkinFactoryおよびSummerSkinFactoryは具象ファクトリとして機能します。
インターフェイスIButton、IComboBox、およびITextFiledは抽象製品として機能し、そのサブクラスSpringButton、SpringComboBox、SpringTextFiledおよびSummerButton、SummerComboBox、およびSummerTextFiledは具象製品として機能します。

ISkinFactory

/// <summary>
/// 界面皮肤工厂接口，充当抽象工厂
/// </summary>
interface ISkinFactory
{
    IButton CreateButton();
    ITextFiled CreateTextFiled();
    IComboBox CreateComboBox();
}

SpringSkinFactory

/// <summary>
/// Spring 皮肤工厂，充当具体工厂
/// </summary>
class SpringSkinFactory : ISkinFactory
{
    public IButton CreateButton()
    {
        return new SpringButton();
    }

    public IComboBox CreateComboBox()
    {
        return new SpringComboBox();
    }

    public ITextFiled CreateTextFiled()
    {
        return new SpringTextFiled();
    }
}

IButton

/// <summary>
/// 按钮接口，充当抽象产品
/// </summary>
interface IButton
{
    void Display();
}

SpringButton

/// <summary>
/// Spring 按钮类，充当具体产品
/// </summary>
class SpringButton : IButton
{
    public void Display()
    {
        Console.WriteLine("显示浅绿色的按钮。");
    }
}

クライアントプログラムのメインコール

//xml配置文件与反射方式扩展
// 1.读取【App.config】配置文件
string factoryString = ConfigurationManager.AppSettings["spring"];
ISkinFactory skinFactory = (ISkinFactory)Assembly.Load("AbstractFactoryPattern").CreateInstance(factoryString);
IButton ibtn = skinFactory.CreateButton();
IComboBox iComBox = skinFactory.CreateComboBox();
ITextFiled iTextFiled = skinFactory.CreateTextFiled();

ibtn.Display();
iComBox.Display();
iTextFiled.Display();

他の実装も同様ですが、ここでは省略します。完全なコードデモを参照してください=》https://gitee.com/dolayout/DesignPatternOfCSharp/tree/master/DesignPatternOfCSharp/AbstractFactoryPattern

3 |抽象ファクトリモデルにおける開始と終了の原則の傾斜

上記のインターフェイススキンライブラリは、新しいタイプのスキンライブラリを簡単に追加できますが、この設計スキームには非常に深刻な問題があります。設計の開始時に設計が包括的でない場合、特定のタイプのインターフェイスコンポーネント（ラジオボタンなど）異なるスキンの下にスタイル表示を提供すると、システムにラジオボタンを追加するのが非常に面倒になります。開閉の原則を満たすことを前提としてラジオボタンを追加することはできません。理由は、ファクトリISkinFactoryは、ラジオボタンの作成をまったく提供していません。このボタンを追加する必要がある場合は、最初に抽象ファクトリインターフェイスISkinFactoryを変更し、ラジオボタンを作成するメソッドを追加してから、の特定のファクトリクラスを変更する必要があります。派生クラスを1つずつ追加し、対応するメソッドを追加して、さまざまなスキンライブラリで使用します。ラジオボタンを作成するには、クライアントも変更する必要があります。そうしないと、既存のシステムでラジオボタンを使用できません。

抽象ファクトリパターンはそのような問題をうまく解決することができず、これは抽象ファクトリパターンの最大の欠点でもあります。抽象ファクトリでは、新製品ファミリを追加するのは便利ですが、新製品の階層構造を追加するのは面倒です。抽象ファクトリモデルのこの特徴は、開閉原理の傾向と呼ばれます。開閉の原則は、システムを拡張のために開いて、変更のために閉じる必要があります。拡張によって機能を強化する目的は、機能を強化する目的を達成することです。複数の製品ファミリと複数の製品階層構造を含むシステムの場合、機能拡張には、次の2つのポイントが含まれます。

（1）製品ファミリの追加：新しく追加された製品ファミリに対応して、抽象ファクトリモデルは開閉の原則を十分にサポートします。特定の製品を追加し、それに応じて新しい特定のファクトリを追加するだけです。既存のコードは必要ありません。。変更。
（2）新しい製品レベル構造の追加：新しい製品レベル構造の追加に対応して、抽象ファクトリクラスを含むすべてのファクトリロールを変更し、すべてのファクトリクラスに新しい製品メソッドを追加する必要があります。クロージング。。

抽象ファクトリモデルは、開閉の原則を満たすための傾斜した方法であるため、設計者は設計の最初に包括的に検討する必要があります。そうしないと、システムに大きな変更が発生し、その後のメンテナンスに多くのトラブルやリスクが発生します。作業。

4 |抽象ファクトリパターンの長所と短所および適用可能なシナリオ

抽象ファクトリパターンは、ファクトリ（メソッド）パターンをさらに拡張したものです。より強力なファクトリクラスを提供し、スケーラビリティが優れているため、ソフトウェア開発、特に一部のフレームワークや設計のAPIライブラリで広く使用されています。抽象ファクトリパターンは、ソフトウェア開発で最も一般的に使用されるデザインパターンの1つです。
4.1抽象ファクトリパターンの主な利点

（1）抽象ファクトリパターンは具象クラスの生成を分離するため、クライアントは何が作成されたかを知る必要がありません。この分離により、コンクリートファクトリの交換が比較的容易になります。すべてのコンクリートファクトリは、抽象ファクトリで定義されたパブリックインターフェイスを実装します。したがって、コンクリートファクトリのインスタンスを変更するだけで、ソフトウェアシステム全体をある程度変更できます。。の動作。
（2）製品ファミリ内の複数のオブジェクトが連携して動作するように設計されている場合、クライアントが常に同じ製品ファミリ内のオブジェクトのみを使用するようにすることができます。
（3）抽象ファクトリモデルは、既存のシステムを変更せずに新しい製品ファミリを追加するのに非常に便利であり、開閉の原則に準拠しています。

4.2抽象ファクトリモデルの主な欠点
新しい製品レベルの構造を追加するのは面倒で、元のシステムに大幅な変更が必要であり、抽象レイヤーコードを変更する必要さえあります。これは明らかに大きな不便をもたらし、の原則に違反します。開閉。

4.3抽象ファクトリパターンの適用環境

（1）システムは、製品クラスインスタンスの作成、結合、および表現の詳細に依存するべきではありません。これは、すべてのタイプのファクトリモデルにとって重要です。ユーザーは、オブジェクトの作成プロセスを気にする必要がなく、オブジェクトの作成と使用。
（2）システムには複数の製品ファミリがありますが、毎回使用される製品ファミリは1つだけです。ユーザーは、構成ファイルやその他の方法で製品ファミリを動的に変更でき、新しい製品ファミリを簡単に追加することもできます。
（3）同じ製品ファミリに属する製品は一緒に使用され、この制約はシステムの設計に反映される必要があります。同じ製品ファミリの製品は無関係なオブジェクトである可能性がありますが、同じオペレーティングシステムのボタンやテキストボックスなど、すべてに共通の制約があります。ボタンとテキストボックスの間に直接的な関係はありませんが、それらはすべて特定の対象に属します。オペレーティングシステムには、現時点で共通の制約があります。オペレーティングシステムのタイプです。
（4）製品グレード構造が安定している設計完了後、システムに新しい製品グレード構造が追加されたり、既存の製品グレード構造が削除されたりすることはありません。