java框架就是调库吗_关于java：Factory方法更适合框架和抽象工厂库吗？

冷不防 2022-11-08 14:15 3阅读 0赞

Abstract Factory和Factory方法模式都是创建设计模式，它解决了不同场景下的对象创建问题。

根据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.

我的理解 ：

客户的动机是获取基础工厂类中存在的方法得到执行，这取决于现在不知道具体类的对象(在这种情况下，无论是在向客户提供软件期间，它都将被定义，或者它将是客户自己编写的具体实现，很可能是在Framework的情况下)。未知(或可能更改)的产品提供了一个抽象类型：IProduct，并设置一个合同，以后在任何产品实现中都必须实现此接口。

IProduct接口

package com.companyx;

public interface IProduct \{

public void serve();

带有'a method'的工厂类需要执行

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

工厂界面，(也可以是抽象类)

package com.companyb;

public interface IFactory \{

public IProductA createProduct();

Factory的具体实现o创建ProductA

package 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();

Q1：抽象工厂模式中是否需要相关产品系列，如果只有一种产品(如上所述)有各种子类型而不是各种相关类型，那么这种模式是否仍然相关？

Q2我的理解是否正确？

Q3 Above在我的脑海中带来了另一个疑问：Factory方法是否更适合于框架(客户端可以提供产品的实现)，就像模板方法模式一样，工厂调用用户提供的具体工厂实现的createProduct()具体实现？

同样，抽象工厂更适合图书馆开发，具体的产品类别(可能会有所不同)隐藏在更稳定的工厂类别背后？

我认为这个问题可以缩短。这将有助于(1)更好地了解您想要问的内容(2)使答案适用于更广泛的社区。就目前而言，这是一个很好的问题，只是有点长。

@inquisitve，你可能是对的，我觉得我可以通过删除代码和使用uml来做到这一点..除了缩短很难

一些观察：(1)Factory class with 'a method' which needs to be executed :: executeJob工厂一般不执行算法。这可能Strategy不是工厂。 (2)Client Code :: void setFactory用客户端代码捕获工厂或捕获产品。如果您已经捕获(在私人变量中)产品，那么为什么要在工厂周围进行检测？

@inquisitve，工厂方法和抽象工厂解决了在不同场景中创建对象的问题，以及它可能会使用模板(继承|工厂方法)并且有点像stratedy(组合|抽象工厂)的交互。

请注意，抽象工厂与工厂方法是Stack Overflow上第二大最受欢迎的设计模式主题，正如我在此处所提到的。

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

首先，library vs framework与工厂，抽象工厂或任何模式无关。图书馆与框架的争论不是从模式发挥作用的实现角度出发的。例如，JUnit是一个带有丰富断言库的框架。那么，对于内部实现，junit是否应该优先选择其他模式？ Java本身是一个带有JCL库的框架。 Dot Net与java类似，甚至称自己为框架，并包含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，我们将其创建的责任委托给ProcessBuilder builder pattern到工厂模式。 jdbc ConnectionManager也是如此。

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

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

在我的理解中：

A1：产品系列不一定需要相关，如示例图所示，只需要具有产品类型知识的客户。 这种关系大多是自然的，因为你可能不希望同一个客户端创建2个不相关的对象，例如，如果你有一个创建Pizza和Cars的"AbstractPizzaFactory"，它看起来会很奇怪，不是吗？

A2：从技术上讲，您可以在Factory模式中提供默认的工厂方法，这样您仍然可以创建(默认)新对象，而无需始终对其进行子类化。

A3：我同意你的观点，尽管创建一个图书馆或一个框架绝不是黑白分明的。

我已经编辑了我的问题。

抽象工厂可以看作是工厂方法的集合。

为了更好地理解现实生活中的例子可以帮助：

工厂方法 - 橡皮泥/模具

抽象工厂 - 卡片厂