对 Factory 所做的一些疑问
我不太确定是否完全理解工厂模式。
假设我有一个类 Customer ，它基本上具有以下方法：
CreateCustomer- 静态，从头开始创建客户并将其添加到数据库，LoadCustomercode> - 静态，从数据库加载Customer实例，KillCustomer- 非静态，从数据库中删除客户。
如果我理解得很好，
LoadCustomer是放入工厂类的一个很好的候选者。CreateCustomer怎么样？我想它可能会被放入工厂类。是这样吗？如果没有，静态CreateCustomer方法将更改数据库状态，然后调用CustomerFactory.LoadCustomer。恕我直言，这是一个糟糕的设计：给定的对象不必知道有关她自己的工厂的任何信息。KillCustomer在我看来，对于工厂来说是一个非常糟糕的候选者：它作用于一个已经创建的对象，而不是创建一个对象。另一方面：- 如果非静态方法从数据库中删除客户，则该对象（从中调用
KillCustomer）仍然存在。看到一个对象在数据库级别自杀而仍然保留在业务级别，这是很奇怪的。在这个级别上，从工厂调用KillCustomer会更合理。例如，如果对象缓存在应用程序中，工厂可能会从数据库和缓存中删除它。 - 将创建对象的方法和删除对象的方法放在不同的类中似乎也很奇怪。 为什么工厂可以只建造一些东西，而不会破坏所建造的东西？
- 如果非静态方法从数据库中删除客户，则该对象（从中调用
最后但并非最不重要的一点是，假设客户缓存在应用程序中。 谁负责管理缓存？ IMO，工厂必须这样做：它创建对象，因此它是选择是否必须加载具有从数据库填充的属性的新对象，或者如果该对象已存在于缓存中。
那么，我对工厂模式的看法什么是正确的，什么是错误的？
I'm not really sure to understand completely the factory pattern.
Let's say I have a class Customer which has basically the following methods:
CreateCustomer- static, creates a customer from scratch and adds it to the database,LoadCustomer- static, loads an instance of aCustomerfrom the database,KillCustomer- not static, removes a customer from the database.
If I understand well,
LoadCustomeris a good candidate to be put into a factory class.- What about
CreateCustomer? I suppose that it may be put into a factory class. Is that right? If not, the staticCreateCustomermethod will change the database state, then callCustomerFactory.LoadCustomer. IMHO, this is bad design: a given object don't have to know anything about her own factory. KillCustomerseems to me a very bad candidate for a factory: it acts on an already created object, rather than creating one. On the other hand:- If a non-static method removes the customer from the database, the object (from which
KillCustomerwas called) still exists. This is quite strange to see an object committing suicide on database level and still remaining on business level. CallingKillCustomerfrom factory would be more reasonable on this level. For example, if the object is cached in application, the factory may remove it both from database and from cache. - Putting in different classes the method which creates an object and the method which removes it seems strange too. Why can factory just build something, and never destroy what was built?
- If a non-static method removes the customer from the database, the object (from which
Last but not least, let's say customers are cached in application. Who is responsible to manage cache? IMO, the factory must do it: it creates the objects, so it is a good candidate to choose if a new object with properties populated from database must be loaded, or if the object already exists in cache.
So, what's right and what's wrong in what I'm thinking about factory pattern?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
工厂不是用来建造东西的。它适用于当您不确切知道要构建什么时构建东西。在我看来，你们所有的方法都不适合工厂。
现在，如果您在以
Customer为根的继承层次结构中有一大堆不同类型的客户，并且有关用于创建客户的数据的一些详细信息确定了创建哪种类型的客户，那么CreateCustomer将是工厂方法的一个很好的候选者。与LoadCustomer相同，因为您可能不完全确定数据库中存储的是哪种类型的客户。但
KillCustomer仍然不是一个好的候选者。那是因为它应该只是一个虚拟方法。然后它就能准确地知道它所呼叫的是哪类客户。Factory is not for building things. It's for building things when you don't know exactly what you're going to build. In my opinion, all of your methods are poor candidates for a factory.
Now, if you had a whole big bunch of different kinds of customers in an inheritance hierarchy rooted at
Customerand some details about the data used to create a customer determined which kind of customer was made, thenCreateCustomerwould be a great candidate for a factory method. The same withLoadCustomersince presumably you aren't completely sure exactly which sort of customer is being stored in the database.But
KillCustomeris still a bad candidate. And that's because it should just be a virtual method. Then it knows exactly which kind of customer it was called on.