很多人说他们在项目中使用工厂模式。但是当我真正看到它们的实现时,它看起来完全不同 从定义我在第一本书中读到的内容。在书中他们描述了两种工厂模式,即
工厂方法: - 一个类指定其子类来指定哪个 要基于某个参数创建的对象。所以我们在这里期待一些 基类中的抽象方法,由子实现 类和pupose将创建一些对象
抽象工厂: - 提供工厂(以界面或 用于创建相关或依赖对象族的抽象工厂 没有具体说明具体的课程。
我在这里有一个问题,他们的意思是依赖或相关的家庭
对象。让我们参考http://www.apwebco.com/gofpatterns/creational/AbstractFactory.html。根据我的理解,这意味着在FinancialToolsFactory
(在链接中)能够创建TaxProcessor
,这是一系列产品,其中所有的concreate产品都是CanadaTaxProcessor
和EuropeTaxProcessor
。所以在这里我们将有n
个具体工厂(在这种情况下为CanadaFinancialToolsFactory
和EuropeFinancialToolsFactory
),在这种情况下将扩展/实现抽象工厂FinancialToolsFactory
。
请告知我上述理解是否正确,因为我认为这是工厂模式的关键。
第二个问题:
人们对工厂模式名称的处理如下:
public class MyFactory
{
public static <T> T getObject(Class<T> cls)
{
if (cls == null)
{
throw new IllegalArgumentException("Invalid className");
}
T daoObject = (T)map.get(cls);
if (daoObject == null)
{
daoObject = loadObject(cls);
}
return daoObject;
}
}
它们只是从main方法传递类似Example.class的类,并获取该特定类的对象实例。 现在,如果我们按照开头(从第一本书)和其他网站描述的工厂模式的实际概念,它不遵循两种工厂模式中的任何一种。对我来说,它看起来像一个实用程序类,我们传递类并获取对象实例。 如果你们同意这个,请告诉我吗?
答案 0 :(得分:7)
您对工厂方法和抽象工厂模式的理解是正确的。
当人们创建其职责仅仅是创建其他对象的类时,他们自然倾向于将它们命名为Factory。这本身并非不合理。问题是没有工厂模式。
出现混乱有两个原因:
有些开发人员只想引入另一种模式并声称他们正在使用“工厂模式”,指的是创建其他模式的对象
了解设计模式的开发人员会看到一个类被称为Factory,无论是否实现了模式,并假设它必须是Factory Method或Abstract Factory。这是令人困惑的,因为你正在试图找出它是哪一个,质疑你自己对真实模式的理解。
请记住,不仅设计模式解决了常见问题,而且它们用于建立讨论设计的语言。在这种情况下,您期望的设计语言不是开发人员实际使用的语言。如果他们说他们使用的是特定的设计模式,他们所做的只是错误的。
答案 1 :(得分:2)
依赖或相关对象系列的含义是什么
使用四人帮的Design Patterns示例:
WidgetFactory
)MotifWidgetFactory
,PMWidgetFactory
)Window
,ScrollBar
)MotifWindow
,MotifScrollBar
,PMWindow
,PMScrollBar
) public abstract class WidgetFactory {...}
public class MotifWidgetFactory extends WidgetFactory {...}
public class PMWidgetFactory extends WidgetFactory {...}
让我们从MotifWidgetFactory
开始吧。它将生产一系列延伸或实施抽象产品的混凝土产品。由于它们都是由同一家工厂建造的,因此它们可以很好地协同工作。您无法使PMScrollBar
使用MotifWindow
。
人们对工厂模式的名称做了以下...它看起来像一个实用程序类,我们传递类并获取对象实例。
您的示例是一个工厂,它生成一个对象。在这种情况下,从Map
检索单例。它不遵循“工厂方法”或“抽象工厂”模式,因此只是名义上的工厂。