问题描述
许多人说他们在他们的项目中使用工厂模式。但是当我实际看到他们的实现时，看起来完全不同于从定义我读到头第一本书。在这本书中，他们描述了两种工厂模式，即
我在这里有一个问题，他们是依赖或相关的
对象的家庭意味着什么。 。根据我的理解，这意味着在 FinancialToolsFactory （在链接中）可以创建 TaxProcessor ，这是一个产品的实际产品是 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;
}
}
他们只是传递类像Example.class从main方法并获取该特定类的对象实例。
现在，如果我们按照开始（从头第一本书）和其他网站描述的工厂模式的实际概念，不遵循两种工厂模式之一。对我来说，它看起来像一个实用程序类，我们传递类并获取对象实例。 请让我知道您是否同意这一点？
抽象工厂模式是正确的。
当人们创建职责仅仅是创建其他对象的类时，他们自然会把它们命名为工厂。这本身并不是不合理的。问题是没有工厂模式。
出现这种混乱有两个原因：
-
一些开发人员只想扔另一个模式，并声称他们使用工厂模式，指的是创建他人的对象
-
开发人员了解设计模式，可以看到一个类被称为工厂，无论是否实现了模式，并假设它必须是工厂方法或抽象工厂。这是令人困惑的，因为你正在找出它是哪一个，质疑你自己对真实模式的理解。
$ b记住，不仅是常见问题的设计模式解决方案，而且它们用于建立讨论设计的语言。在这种情况下，您期望的设计语言不是开发人员实际使用的。他们正在做的只是错误的，如果他们说他们正在使用特定的设计模式。
Many people say they are using factory pattern in their project. But when i actually see their implementation it looks totally differentfrom definition what i have read in head first book. In the book they have described two kind of factory pattern i.e
I have a question here on what do they mean by family of dependent or relatedobjects. Lets refer to http://www.apwebco.com/gofpatterns/creational/AbstractFactory.html. As per my understanding it means that in FinancialToolsFactory (in the link) is able to create TaxProcessor which is a family of products where actuall concreate products are CanadaTaxProcessor and EuropeTaxProcessor . So here we will have n number of concrete factories(in this case CanadaFinancialToolsFactory and EuropeFinancialToolsFactory) which will be extending/implementing abstract factory in this case FinancialToolsFactory.
Please let me know if above understanding is correct as i think its the crux of Factory pattern.
Second question:
What people are doing on the name of factory pattern is below:
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;
}
}
They are just passing class like Example.class from main method and getting the object instance for that specific class.Now if we go by actual concept of factory pattern which is described in beginning(from head first book) and other websites it does not follow any of the two factory patterns. To me it looks like a utility class where we are passing the class and getting the object instance. Please let me know if you folks agree with this?
Your understanding of the Factory Method and Abstract Factory patterns is correct.
When people create classes whose responsibility is solely to create other objects, they naturally tend to name them Factory. That in itself isn't unreasonable. The problem is that there is no Factory pattern.
Confusion arises here for two reasons:
Some developers just want to throw in another pattern and claim that they're using the "Factory Pattern," referring to the object that creates others
Developers learning about design patterns see that a class is called a Factory, regardless of whether a pattern is implemented, and assume it must be a Factory Method or Abstract Factory. This is confusing because you're then trying to figure out which one it is, calling into question your own understanding of the real patterns.
Remember that not only are design patterns solutions to commonly encountered problems, but that they serve to establish a language for discussing design. In this case, the design language you expect is not what the developer actually used. What they are doing is only wrong if they say they are using a specific design pattern.
这篇关于有关工厂模式的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！