2.0 - 三銃士のデザインパターンの工場出荷時のパターン - シンプルなファクトリパターン

2.0デザインパターン工場パターン

まずリコール設計の原則:

設計の原則 説明
オープンクローズ原理 拡張のために開きますが、変更のため閉鎖。
依存関係逆転の原則 それぞれのクラスやモジュールを抽象化することで、互い、疎結合に影響を与えません。
単一責任の原則 クラス、インタフェース、メソッド、一つだけ
インターフェイスの棲み分け原理 インタフェースの純度を確保しようとすると、クライアントが不要なインタフェースを頼るべきではありません。
デメテル また、最小の原則として、より良いクラスは、そのクラスに依存し、知っている、知っている知られています。
リヒターの置換原則 サブクラスは、親クラスの機能を拡張することができますが、元の関数の親クラスを変更することはできません。
多重化原則の合成 再利用をコーディングするオブジェクトの継承関係を使用せずに、オブジェクト合成、重合を利用すること。

ファクトリモードは、詳細な

工場出荷時のパターンの歴史的起源

実際の生活の中で、私たちは皆知っている、オリジナルの社会的自立(無工場)、小さな農業コミュニティワークショップ(簡単な植物、市民蒸留所)、産業革命ライン(ファクトリメソッド、国産)、近代的な産業チェーンファウンドリ(抽象工場、Foxconnの)

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

シンプルなファクトリパターン(簡易ファクトリパターン)は、工場製品カテゴリのインスタンスを作成し、オブジェクトの決定を意味するが、それはGOF属していない、シンプルなファクトリクラスは、シーンを作成するために少数のオブジェクトに責任がある工場で使用されるデザインパターンの23種類、そしてクライアントは気にしないロジックのオブジェクトを作成する方法を、工場出荷時のクラスにパラメータを渡す必要があります。次はコードを見て

私たちは、コースICAR標準インタフェースを定義することができます。

 

/**
 * 汽车接口
 */
public interface ICar {
    void run();
}
/**
 * 奥迪类
 */
public class AudiCar implements ICar {
    @Override
    public void run() {
        System.out.println("奥迪跑起来了");
    }
}
public static void main(String[] args) {
        ICar iCar=new AudiCar();
        iCar.run();
}

親クラスの参照は、サブクラスAudiCarを意味し、上記のコードを見て()、コードのアプリケーション層はAudiCarを頼る必要があり、事業拡大ならば、私はますます肥大化になるために私たちのクライアントに依存して、その後、さらに増加し​​続けCadillacCar。したがって、我々は隠された詳細を作成するには、この依存性を減少させる方法を見つけます。現在のコードが、我々は、プロセスのオブジェクトを作成し、複雑ではなく、ビューのコード設計のポイントは、拡張することは容易ではありません。今、私たちは、コードを最適化するために、単純なファクトリパターンを使用します。

/**
 * 凯迪拉克类
 */
public class CadillacCar implements ICar {
    @Override
    public void run() {
        System.out.println("凯迪拉克跑起来了");
    }
}

ファクトリクラスし、SimpleFactoryを作成し、我々は植物を作成するには、次の3つのメソッドを与えます

 /**
     * 创建实例
     * @param type
     * @return
     */
    public ICar create(String type){
      if(StringUtils.isEmpty(type)){
         return null;
      }
      if("Audi".equals(type)){
          return new AudiCar();
      }else if("Cadillac".equals(type)){
         return new CadillacCar();
      }else {
          return null;
      }
    }
/**
     * 通过反射创建,不修改代码逻辑
     * @param className
     * @return
     */
    public ICar createByclazz(String className){
        try {
            if (!(null == className || "".equals(className))) {
                return (ICar) Class.forName(className).newInstance();
            }
        }catch (Exception e){
            e.printStackTrace();
        }
        return null;
    }
/**
     * 通过类实例化,方法参数是字符串,可控性有待提升,而且还需要强制转型
     * @param clazz
     * @return
     */
    public ICar create(Class<? extends ICar> clazz){
        try {
            if (null != clazz) {
                return clazz.newInstance();
            }
        }catch (Exception e){
            e.printStackTrace();
        }
        return null;
    }

クライアントを呼び出すコード

/**
 * 简单工厂模式测试类
 * 优点:把创建代码封装到工厂里,调用者感应不到,只需要传入响应的类型即可
 * 缺点:不符合开闭原则,没增加一个产品都要修改工厂代码,不易于扩展
 */
public class SimpleFactoryTest {

    public static void main(String[] args) {
        SimpleFactory simpleFactory=new SimpleFactory();
        ICar iCar= simpleFactory.create("Audi");
        iCar.run();

        //通过反射调用
        ICar iCar1=simpleFactory.createByclazz("com.design.pattern.common.AudiCar");
        iCar1.run();

        ICar iCar2=simpleFactory.create(AudiCar.class);
        iCar2.run();
    }
}

のは、クラス図を見てみましょう:

JDKのソースのシンプルな工場出荷時のパターンは、我々は今、このようなCalendarクラスとして、あなたの例を与える、どこにでもある、Calendar.getInstance()メソッドを参照してください、次はカレンダーのクラスを作成するためのオープンコンクリートは次のとおりです。

private static Calendar createCalendar(TimeZone zone,Locale aLocale)
{
                CalendarProvider provider =
        LocaleProviderAdapter.getAdapter(CalendarProvider.class, aLocale)
        .getCalendarProvider();
        if (provider != null) {
        try {
        return provider.getInstance(zone, aLocale);
        } catch (IllegalArgumentException iae) {
        // fall back to the default instantiation
        }
        }
        Calendar cal = null;
        if (aLocale.hasExtensions()) {
        String caltype = aLocale.getUnicodeLocaleType("ca");
        if (caltype != null) {
        switch (caltype) {
        case "buddhist":
        cal = new BuddhistCalendar(zone, aLocale);
        break;
        case "japanese":
        cal = new JapaneseImperialCalendar(zone, aLocale);
        break;
        case "gregory":
        cal = new GregorianCalendar(zone, aLocale);
        break;
        }
        }
        }
        if (cal == null) {
        // If no known calendar type is explicitly specified,
        // perform the traditional way to create a Calendar:
        // create a BuddhistCalendar for th_TH locale,
        // a JapaneseImperialCalendar for ja_JP_JP locale, or
        // a GregorianCalendar for any other locales.
        // NOTE: The language, country and variant strings are interned.
        if (aLocale.getLanguage() == "th" && aLocale.getCountry() == "TH") {
        cal = new BuddhistCalendar(zone, aLocale);
        } else if (aLocale.getVariant() == "JP" && aLocale.getLanguage() == "ja"
        && aLocale.getCountry() == "JP") {
        cal = new JapaneseImperialCalendar(zone, aLocale);
        } else {
        cal = new GregorianCalendar(zone, aLocale);
        }
    }
	return cal;
}

そこ私たちはしばしばlogbackを使用して、我々はLoggerFactoryオーバーロードされたメソッドのgetLogger()よりもそこにあることがわかります。

public static Logger getLogger(String name) {
	ILoggerFactory iLoggerFactory = getILoggerFactory();
	return iLoggerFactory.getLogger(name);
}
public static Logger getLogger(Class clazz) {
	return getLogger(clazz.getName());
}

シンプルな工場にも欠点がある:責任ファクトリクラスが比較的重く、過度に複雑な製品構造を拡張することは困難です。

おすすめ

転載: blog.csdn.net/madongyu1259892936/article/details/93747664