设计模式(三)——工厂方法模式

忘是亡心i 2022-05-27 02:45 186阅读 0赞

### 一、工厂方法模式 ###

**1、模式动机**

考虑这样一个系统，按钮工厂类可以返回一个具体的按钮实例，如圆形按钮、矩形按钮、菱形按钮等。在这个系统中，如果需要增加一种新类型的按钮，如椭圆形按钮，那么除了增加一个新的具体产品类之外，还需要修改工厂类的代码，这就使得整个设计在一定程度上违反了“开闭原则”。

现在我们对该系统进行改进，不再设计一个按钮工厂来统一负责所有产品的创建，而是将具体按钮的创建过程交给专门的工厂子类去完成，我们先定义一个抽象的按钮工厂类，再定义具体的工厂类来生成圆形按钮、矩形按钮等，它实现在抽象按钮工厂类中定义的方法。这种抽象化的结果使这种结构可以在不修改具体工厂类的情况下引进新产品，如果出现新的按钮类型，只需要为这种按钮类型创建一个具体的工厂类就可以获得该新按钮的实例，这一特点无疑使得工厂方法模式具有超越简单工厂模式的优越性，更加符合“开闭原则”。

**2、模式定义**

工厂方法模式又称为工厂模式，也叫虚拟构造器模式或者多态模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

**3、模式结构**

![70][]

• Product：抽象产品

• ConcreteProduct：具体产品

• Factory：抽象工厂

• ConcreteFactory：具体工厂

**4、模式分析**

工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了面向对象的多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不负责哪一个产品类被实例化的这种细节，这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。

当系统扩展需要添加新的产品对象时，仅仅需要添加一个具体产品对象以及一个具体工厂对象，原有工厂对象不需要进行任何修改，也不需要修改客户端，很好的符合了“开闭原则”。而简单工厂模式添加新产品对象后不得不修改工厂方法，扩展性不好。工厂方法模式退化后可以演变成简单工厂模式。

**3、模式实例与解析**

①抽象工厂代码

public abstract class PayMethodFactory{
        public abstract AbstractPay getPayMethod();
    }

②具体工厂类

public class CashPayFactory extends PayMethodFactory{
        public AbstractPay getPayMethod(){
            return new Cash();
        }
    }

③客户类代码片段

PayMethodFactory factory;
    AbstractPay payMethod;
    factory = new CashPayFactory();
    payMethod = factory.getPayMethod();
    payMethod.pay();

为了提高系统的可扩展性和灵活性，在定义工厂和产品时都必须使用抽象层，如果需要更换产品类，只需要更换对应的工厂即可，其他代码都不需要进行修改。

工厂方法模式又称工厂模式或多态工厂模式，属于创建型模式。在该模式中父类负责创建产品的公共接口，子类负责负责具体的产品实现。将产品的实例化操作延迟到子类中。

**4、实例**

public interface Car {
        public void run();
    }

public class Audi implements Car {
        @Override
        public void run() {
            System.out.println("Audi run");
        }
    }

public class BYD implements Car{
        @Override
        public void run() {
            System.out.println("BYD run");
        }
    }

public interface CarFactory {
        Car getCar();
    }

public class AudiFactory implements CarFactory{
    
        @Override
        public Car getCar() {
            return new Audi();
        }
    }

public class BYDFactory implements CarFactory {
        @Override
        public Car getCar() {
            return new BYD();
        }
    }

public class User {
        public static void main(String[] args) {
            Car car = new AudiFactory().getCar();
            car.run();
        }
    }

![70 1][]** 5、简单工厂模式和工厂方法模式**

*  结构复杂度  
    从这个角度上比较，显示简单工厂模式要占优势。简单工厂模式只需要一个工厂类，而工厂方法模式的工厂随类的数量增加而增加，无疑会使类的个数越来越多，从而增加了结构的复杂度。
 *  代码复杂度  
    代码复杂度和结构复杂度是一对矛盾，既然简单工厂模式在结构方面相对简洁，那么它在代码方面相对工厂方法模式要更加复杂。简单工厂模式的工厂类随着产品类的增加需要增加很多方法（或代码），而工厂方法的工厂类只需要完成单一任务，代码简洁。  
     
 *  客户端编程难度  
    工厂方法模式虽然在工厂类结构中引入了接口从而满足了OCP，但是在客户端中需要对工厂类进行实例化。但是简洁工厂模式的工厂是一个静态类，在客户端无需实例化，这无疑是一个吸引人的优点。  
     
 *  管理上的难度  
    从扩展角度上看，工厂方法模式完全满足OCP，即它有非常好的扩展性。但是简单工厂模式也具有良好的扩展性，只需要修改工厂类中少量代码就可以满足扩展要求了。尽管这没有完全满足OCP，但我们不能太过拘泥于设计模式。  
    从维护性上看，如果对某个具体的产品类进行一定修改，很可能需要修改对应的很多个产品类，工厂方法就变得非常麻烦。简单工厂模式仅仅需要修改唯一的工厂类。

根据设计理论建议：工厂方法模式。但实际，我们一般使用简单工厂模式。

[70]: /images/20220527/e685408b38034ec1a555b8ab078da7e8.png
[70 1]: /images/20220527/274a7ada7651475da1067d846c2b7ec3.png