デザインパターン - 詳細シンプルなファクトリパターン

シンプルなファクトリパターンのコンセプト

　　シンプルなファクトリパターンは、オブジェクトの作成に焦点を当て生成に関するデザインパターンの一部です。

　　持ち帰りの時点を、あなたがアリペイ、マイクロチャネル支払い、ApplePayおよび他の支払方法を使用するように選択することができ、のは、支払いのシナリオを考えてみましょう。

　　これらの支払名前が同じではないが、しかし、使用量および実質的に同様の手順は、正当性を含め、セキュリティ検証支払いのパスワードを確認するために、アカウントの支払い環境、デビットアカウントをチェックし、ユーザーは他の関数の結果を通知支払います。

　　共通している、私たちは抽象基本クラスを持って、その後、支払いサブクラスのすべての種類は、独自のビジネス・ロジックを実装し、それを継承します。

　　我々はこれらの支払方法を使用する場合は、支払いのこれらの特定のサブクラスの名前を知っている必要はありませんが、支払いは名前だけを知っている必要があり、メソッドに渡された名前は、この時点で、対応するオブジェクトを返すためには、使用することができますシンプルなファクトリパターン。

第二に、実現

　　図1に示すように、第1の支払方法の様々な抽象クラスを定義し、単純にそれは通常、支払いであるかどうかを決定するためにアカウントを定義し、いくつかの方法は、ユーザに通知します

名前空間し、SimpleFactory 
{ 
    使用してシステムを、

    パブリック 抽象 クラスAbstractPaymentMethod 
    { 
        ///  <要約> 
        /// か否かを判断するユーザのアカウント通常
         ///  </要約> 
        ///  <PARAM NAME = "ACCOUNTNUMBERの"> アカウント</ param>の
        / //  <戻り値> 通常のアカウント</戻り値> 
        パブリック 抽象 BOOL IsAccountNormal（文字列ACCOUNTNUMBERのを）; 

        ///  <要約> 
        /// ユーザーに通知
         ///  </要約> 
        ///  <PARAM NAME = "メッセージ">通知内容</ param>の
        パブリック 抽象 ボイド NoticeUser（文字列メッセージ）。

        ///  <要約> 
        /// 支付过程
         ///  </要約> 
        ///  <PARAM NAME = "ACCOUNTNUMBER"> 用户账号</ param>の
        ///  <PARAM NAME = "量"> 金额</ PARAM > 
        パブリック 仮想 ボイドペイ（文字列 ACCOUNTNUMBER、小数量）
        { 
            場合（この.IsAccountNormal（ACCOUNTNUMBER））
            { 
                Console.WriteLineを（$ "）;
                 この .NoticeUser（$ " 親愛なる{ACCOUNTNUMBER}、あなたが成功した{量}元を支払いました" ）; 
            } 
        } 
    } 
}

　　アリペイ、マイクロチャネルの賃金を達成するために2、

使用してシステムを。

名前空間し、SimpleFactory 
{ 
    パブリック クラスアリペイ：AbstractPaymentMethod 
    { 
        公共 オーバーライド ブール IsAccountNormal（文字列ACCOUNTNUMBER）
        { 
            返す 真。
        } 

        パブリック オーバーライド ボイド NoticeUser（文字列メッセージ）
        { 
            Console.WriteLineを（" 支付宝支付" ）。
            Console.WriteLineを（メッセージ）。
        } 

    } 
}

使用してシステムを。

名前空間し、SimpleFactory 
{ 
    パブリック クラスWeiXinPay：AbstractPaymentMethod 
    { 
        公共 オーバーライド ブール IsAccountNormal（文字列ACCOUNTNUMBER）
        { 
            返す 真。
        } 

        パブリック オーバーライド ボイド NoticeUser（文字列メッセージ）
        { 
            Console.WriteLineを（" 微信支付" ）。
            Console.WriteLineを（メッセージ）。
        } 
    } 
}

　　3、およびこれら2回の支払いを作成するためのファクトリを定義。ファクトリメソッドは、必要な支払いを決定するために列挙された値（PaymentMethodEnum）、によりここに決定されます

名前空間し、SimpleFactory 
{ 
    使用してシステム。

    パブリック クラスPaymentMethodFactory 
    { 
        パブリック 静的AbstractPaymentMethod GetPaymentMethod（PaymentMethodEnum PAYMENTMETHOD）
        { 
            スイッチ（PAYMENTMETHOD）
            { 
                ケースPaymentMethodEnum.AliPay：
                     戻り 新しいAlipayのを（）;
                ケースPaymentMethodEnum.WeiXinPay：
                     返す 新しいWeiXinPayを（）;
                デフォルト：
                     スロー 新しいです NotImplementedExceptionを（）;
            }
        } 
    } 
}

列挙型クラス

名前空間し、SimpleFactory 
{ 
    パブリック 列挙PaymentMethodEnum 
    { 
        ///  <まとめ> 
        /// Alipayの
         ///  </要約> 
        アリペイ= 0 、

        ///  <要約> 
        /// マイクロチャネル支払い
         ///  </要約> 
        WeiXinPay = 1 
    } 
}

　　4、アナログクライアントは、およそ呼び出します

名前空間し、SimpleFactory 
{ 
    使用してシステム。

    クラスプログラム
    { 
        静的 ボイドメイン（文字列[]引数）
        { 
            AbstractPaymentMethodアリペイ = PaymentMethodFactory.GetPaymentMethod（PaymentMethodEnum.AliPay）。
            AbstractPaymentMethod weiXinPay = PaymentMethodFactory.GetPaymentMethod（PaymentMethodEnum.WeiXinPay）。
            aliPay.Pay（" ヴィンセント" 、700M）。
            Console.WriteLineを（" ********************************* " ）; 
            weiXinPay.Pay（" 123456 " 、1000M）。
            Console.ReadKey（）; 
        } 
    } 
}

　　5、結果を見て

第三に、要約

　　利点のシンプルなファクトリパターン：

ファクトリクラスは、クライアントが製品のオブジェクトを直接、唯一の「消費者」製品の作成に責任を免除することができるどのような時に作成された製品クラスのどのインスタンスを決定することができ、必要な論理判断を含んでいる;責任の実践を通じて達成シンプルなファクトリパターンをオブジェクトを作成するための専門工場クラスを提供部門、。
クライアントは、対応するパラメータをすることができ、特定の製品クラスを知っている必要があり、いくつかの複雑なクラス名のために、簡単なファクトリパターンがユーザメモリの量を減らすことができますのみ作成されたクラス名、特定の製品カテゴリを知っている必要はありません。
設定ファイルを導入することで、あなたは変更することができますし、任意のクライアント側のコードを変更せずに、新たな特定の製品カテゴリを追加し、ある程度のシステムの柔軟性を向上させます。

　　シンプルなファクトリパターンの欠点：

それは動作しません一度ファクトリクラスは、すべての製品の作成ロジックを集中するので、システム全体が影響を受けなければなりません。
システムでファクトリクラスの数を増加させる単純なモデルを使用して、複雑さと、特定のプログラムでシステムを理解することの難しさを増します。
、新製品は、製品の多くの種類がある場合には、植物を変更するロジックを追加する必要があります植物のロジックが複雑すぎる可能性がありたら、困難なシステム拡張には、システムの拡張やメンテナンスを助長されていません。
静ファクトリメソッドの使用に簡単な工場パターン、工場の役割をもたらすことは、継承に基づいて階層を形成することができません。

　　上記の利点と欠点をもとに、簡単な工場出荷時のパターンは、次のシナリオに適用されます。

オブジェクトファクトリクラスは、比較的小さな作成するための責任がある：以下により作成されたオブジェクトに、ファクトリメソッドがあまりにも複雑なビジネスロジックを引き起こすことはありません。
クライアントは気にしないオブジェクトを作成する方法、ファクトリクラスを渡されたパラメータを知っている：クライアントは、作成の詳細についてどちらも注意が必要で、でも、クラスの名前は唯一、対応するパラメータの種類を知っておく必要があることを覚えておく必要はありません。

　　ダウンロードコード：https://github.com/hzhhhbb/SimpleFactory

第四に、参考文献

　　https://design-patterns.readthedocs.io/zh_CN/latest/creational_patterns/simple_factory.html#id2

デザインパターン - 詳細シンプルなファクトリパターン

おすすめ