著作権:帰属、紙ベースを作成するために他人を許可し、(同じライセンスで元のライセンス契約に基づいて用紙配布する必要がありますクリエイティブコモンズ)
定義と種類
定義:作成したオブジェクトのインタフェースの定義
が、のは、このインタフェースの実装クラスのインスタンスを生成するクラスを決定させ
サブクラスが行わできるように延期インスタンス化するファクトリメソッドを
型を作成するタイプ
該当シーン
オブジェクトを作成すると、反復コードの多くを必要と
クライアント(アプリケーション層)は、実現の詳細、製品クラスのインスタンスが作成される方法に依存しません
そのサブクラスによって作成されたオブジェクトを指定するクラス
利点
ユーザーは、作成の詳細については気にすることなく、植物に対応して所望の生成物を気にする必要があります
開閉、拡張性の原則と新製品ラインを追加します。
リヒター置換原則は原則開閉:使用ソフトウェア設計の原則
オブジェクト指向の多型を使用して
短所
クラスの数があまりにも簡単
システムの複雑さが抽象的で理解しにくい増加増加
ショー
ケーキ抽象クラスを作成します。
package softwareDesign.coding.factoryMethod;
public abstract class Cake {
public abstract void produce();
}
チョコレートケーキ
package softwareDesign.coding.factoryMethod;
public class CCake extends Cake{
@Override
public void produce() {
System.out.println("生产巧克力蛋糕");
}
}
雪のケーキ
package softwareDesign.coding.factoryMethod;
public class SnowCake extends Cake{
@Override
public void produce() {
System.out.println("生产雪花蛋糕");
}
}
抽象ファクトリクラスを作成します。
package softwareDesign.coding.factoryMethod;
public abstract class CakeFactory {
public abstract Cake getCakeFactory();
}
チョコレートケーキファクトリーを作成します。
package softwareDesign.coding.factoryMethod;
public class CCakeFactory extends CakeFactory{
@Override
public Cake getCakeFactory() {
return new CCake();
}
}
スノーフレークケーキの生産工場を作成します。
package softwareDesign.coding.factoryMethod;
public class SnowCakeFactory extends CakeFactory {
@Override
public Cake getCakeFactory() {
return new SnowCake();
}
}
テスト:
package softwareDesign.coding.factoryMethod;
public class Test {
public static void main(String[] args) {
CakeFactory cakeFactory = new CCakeFactory();
Cake cake = cakeFactory.getCakeFactory();
cake.produce();
CakeFactory cakeFactory2 = new SnowCakeFactory();
Cake cake2 = cakeFactory2.getCakeFactory();
cake2.produce();
}
}
組み合わせることで、簡単な工場を理解します
私たちは、UMLダイアグラムを見て
拡張された場合は、ケーキの新しいタイプを追加し、工場は、コアコードに触れることなく、「外ブブに」ちょうどあります。非常に巧妙に解決されたファクトリメソッドを簡単に確認することができ、製品グループの問題を