java - 工厂方法更适合框架和库的抽象工厂吗？

Question

抽象工厂模式和工厂方法模式都是创建型设计模式，它们解决了不同场景下的对象创建问题。

根据 GOF 工厂方法 图案

Define an interface for creating an object, but let the subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclass.

我的理解:
的动机客户 是获取一个存在于基础工厂类中的方法得到执行，该方法依赖于一个具体类现在未知的对象(在这种情况下，在向客户端提供软件期间，它将被定义，或者它将是客户自己编写具体的实现，很可能是在框架的情况下)。未知(或可能更改)的 Product 提供了一个抽象类型:IProduct，并设置了一个约定，将来 Product 的任何实现都必须实现此接口(interface)。

I产品接口(interface)

package com.companyx;
public interface IProduct {
    public void serve();
}

需要执行的带有“方法”的工厂类

package com.companyx;
public abstract class Factory {
    public abstract IProduct createProduct();
    private void performCriticalJob(){
        IProduct product = createProduct();
        product.serve();
    }
    public void executeJob(){
        //some code
        performCriticalJob();
        //some more code
    }
}

一些具体产品

package com.companyx;
class AppAProductFeatureX implements IProduct{
    @Override
    public void serve() {
        //some code
    }
}

混凝土制品厂

package com.companyx;
public class AppAFeatureXProductFactory extends Factory{
    @Override
    public IProduct createProduct() {
        return new AppAProductFeatureX();
    }
}

客户代码

package com.clientcompany;
import com.companyx.AppAFeatureXProductFactory;
import com.companyx.Factory;
public class Client {
    public static void main(String[] args) {
        Factory fact = new AppAFeatureXProductFactory();
        fact.executeJob();
    }
}

根据 GOF 抽象工厂 图案

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

我的理解
客户对产品感兴趣，这里这种模式通过将具体的产品类隐藏在工厂类后面来帮助提供产品。

客户想要的产品类型

package com.companyb;
public interface IProductA {
    public void performAJob();
}

产品实现

package com.companyb;
//can be named better, but lets go with this name for this time
public class ProductAVersion1 implements IProductA{
    @Override
    public void performAJob() {
        // some code
    }
}

工厂接口(interface) ,(也可以是抽象类)

package com.companyb;
public interface IFactory {
    public IProductA createProduct();
}

Factory o create ProductA的具体实现

包 com.companyb;

public class FactoryA implements IFactory{
    @Override
    public IProductA createProduct() {
        return new ProductAVersion1(); // concrete class of product is hidden
    }
}

客户代码

package com.clientcompany.productprovider;
import com.companyb.IFactory;
import com.companyb.IProductA;
public class SomeClientClass {
    private IFactory factory;
    private IProductA product;

    public void doSomeJobWithProductA() {
        // some code
        product.performAJob();
        //someCode();
    }
    public void setFactory(IFactory factory) {
        this.factory = factory;
        this.product = factory.createProduct();
    }
}

package com.clientcompany.productprovider;
import com.companyb.FactoryA;
public class SomeOtherClientCode {
    public static void main(String[] args) {
        SomeClientClass someClientClass = new SomeClientClass();
        someClientClass.setFactory(new FactoryA());
        someClientClass.doSomeJobWithProductA();
    }
}

第一季度 :抽象工厂模式中是否需要相关产品系列，如果只有一种产品(如上)有各种子类型但没有各种相关类型，这种模式是否仍然相关？

Q2 我上面的理解正确吗？

第三季度上面又带来了一个疑问:工厂方法是否更适合框架(客户端可以提供产品的实现)，就像模板方法模式一样，工厂调用 createProduct()用户提供的具体实现形式具体工厂实现？
同样，抽象工厂更适合库开发，其中具体的产品类(可能会有所不同)隐藏在更稳定的工厂类后面？

Answer 1

我很难穿上你的鞋子。但是我对这个主题很感兴趣，所以我会尝试一下。这里涉及的概念如 library , framework , factory method , abstract factory和 product family等等。

一、library vs framework实际上与工厂、抽象工厂或任何模式无关。库与框架的辩论不是从模式发挥作用的实现角度来看的。例如，JUnit 是一个带有丰富断言库的框架。那么，junit 是否应该更喜欢一种模式而不是其他模式来实现其内部实现？ Java 本身是一个带有 JCL 库的框架。类似于java的Dot Net甚至称自己为框架，并包含BCL库。因此，在实现上下文中不再有框架与库的争论。

所以问题归结为您应该使用哪种模式？这不是关于区别，这很清楚，而是关于在哪种情况下使用哪个。在这种情况下，Client Code是所有可能 call 的代码您现在正在输入的那个。某些代码是由您还是其他人编写的，在相同或不同的 jar 中，来自相同或不同的组织，都没有关系。从一个代码片段的角度来看，任意 其他代码(即使在同一类的不同方法中)是客户端代码，如果该代码有可能 call您现在正在输入的代码。

在键入任何代码时(无论框架或库状态如何)，有时我们需要获取某个对象的实例。可能我们需要一个 BufferedReader .如果在编译时我们绝对确定对象的具体类，KISS随它去new ing。

我们可能不知道实例的具体类。现在问题是客户端代码是否有这些信息？如果客户端代码知道实际的具体类，但我不知道，那么我们使用 FactoryMethod图案。我输入的代码将在(比如说)它的参数列表中请求一个工厂对象的实例。知道实际具体类的客户端代码将提供一个工厂对象来进行创建。这种情况的例子见 JDBC就像我们要处理一条 sql 语句一样。在编译时我们不知道是否应该实例化 mysql.JDBC4PreparedStatement或 microsoft.SQLServerStatement .它取决于连接字符串，这取决于最终用户。所以我们得到一个Connection实例并将其发送至 createStatement() .看，我们正在委派一个类型为 sql.Statement 的对象的构造。到 sql.Connection 的子类.这里 conn实例是工厂对象。我们如何获得工厂并不重要，只是我们从客户端代码中获得了它。

如果我们需要 Process 的实例对象，在编译时我们不知道它是否会是 Win32Process或 UnixProcess ，我们将创建它的责任委托(delegate)给 ProcessBuilder这是builder pattern与工厂模式有关。 jdbc ConnectionManager 也是如此.

如果有许多不同的类不是通过继承而是通过家庭我们可以使用 AbstractFactory .比如jdbc的点网对应DbProviderFactory .我的代码需要 Connection 的实例, Command , DataReader等等，它们不是通过继承而是由 MySql 或 SqlServer 的家族相关的。所以我们得到了 DbProviderFactory 的子类的一个实例。 .可能是 MySqlProviderFactory或 SqlProviderFactory这取决于运行时和客户端代码。一旦我们有了那个工厂，我们就可以做 CreateCommand() , CreateConnection()等等。

希望这可以帮助您在工厂模式和抽象工厂模式之间进行选择。