【対象向けPHP】のパターン:抽象工場アプローチ

抽象ファクトリメソッドモード
ファクトリメソッドモードでは,ミドルウェア方式により,以下のフォーマットの分離を形成した.
利用者↓作成者↓具体的な製品
に質問
これにより、具体的な製品をどのように修正しても、使用者に影響を与えません.今、私たちは小さな工場を作ることができます.彼らはそれぞれの製品を持っていますが、モデルレベルの重複を形成しています.では、私たちはどのようにこのような重複を解消しますか.
本編では、抽象工場メソッドモデルである抽象工場メソッドモデルを通じて、小企業の統合を完了し、最初の設計(親会社-子会社):
次に、抽象クラスを使用して複数のビジネス並列の問題を解決します.
ここで、PIMのデータフォーマットデコーダであるPersonal Information Managementを書くと、予約(Appt)、保留(Ttd)、連絡先(Contact)の3つのデータフォーマットが生成されます.
次のUMLを設計できます.CommsManager抽象クラスにより、特定のすべての子会社(サブクラス)を生成できます.
しかし、実際には、なぜ一部の会社がいくつかの業界にうまくいかないのかをある程度示しており、彼が間接的に子会社に介入しても、子会社の血統に影響を与える(この考えは私が呉軍さんの「Inspurの頂点」に最初に接触した).
インプリメンテーション

abstract class CommsManager {
    abstract function getHeaderText();
    abstract function getApptEncoder();
    abstract function getTtdEncoder();
    abstract function getConteactEncoder();
    abstract function getFootText();
}

class BloggsCommsManager extends CommsManager {
    function getHeaderText()
    {
        return "BloggsCal header
";
    }

    function getApptEncoder()
    {
        return new BloggsApptEncoder();
    }

    function getTtdEncoder()
    {
        return new BloggsTtdEncoder();
    }

    function getConteactEncoder()
    {
        return new BloggsConteactEncoder();
    }

    function getFootText()
    {
        return "BloggsCal footer
";
    }
}

ここでは、ファクトリモード(ディレクトリは最後)を使用しました.設計モード間では、あるモードの作成が、別のモードの一部になることがよくあります.
この方面の考えはモード自身に由来する:彼は無数の同条件の下で、実践して得た最適解である--未来にもっと良い条件があれば、この最適解は依然として最適化の空間/あるいは存在しない.
結果
パターンの意味:

は、ビジネスニーズと実装の詳細を徹底的に分割し、ビジネス層にBUGが発生することを心配することなく、コードフォーマットを任意に変更することができます.

強制統合により、すべてのBloggerフォーマットの内容は、Blogger作成者クラスによって実現され、エラーは発生しません.

もちろん、新製品の追加は悩ましいものであり、新製品の具体的な実装を作成するためには、抽象的な作成者、および彼の各具体的な実装を修正する必要があります.

PHPは現在、メソッドの戻りタイプを強制していないため、いくつかの追加の柔軟性が発生しています.(強制規定戻りタイプは、一般的にJAVAのような強いタイプ-オブジェクト向け-言語)

abstract class CommsManager {
    const APPT    = 1;
    const TTD     = 2;
    const CONTACT = 3;
    abstract function getHeaderText();
    abstract function mark( $flag_int );
    abstract function getFootText();
}

class BloggsCommsManager extends CommsManager {
    function getHeaderText()
    {
        return "BloggsCal header
";
    }

    function mark( $flag_int )
    {
        switch ($flag_int) {
            case self::APPT:
                return new BloggsApptEncoder();
            case self::TTD:
                return new BloggsTtdEncoder();
            case self::CONTACT:
                return new BloggsConteactEncoder();
        }
    }

    function getFootText()
    {
        return "BloggsCal footer
";
    }
}

クラスのインタフェースはよりコンパクトになりますが、一定の代価もあります.詳細なデータフォーマット方法を放棄し、その中で心を込めました.お客様は必要な具体的な製品が実現されたかどうかを確認できません.だから、気をつけて~
あなたのプロジェクトでは、製品がますます多くなり、作成者の数も膨大になります.次の記事では、抽象的な工場方法の変体を紹介します.プロトタイプモデルでは、作成するクラスを減らすことができます.
オブジェクト向け設計モード-ディレクトリ