关于工厂做什么的一些疑问

Question

我不太确定完全了解工厂模式。

假设我有一个类Customer，基本上有以下几种方法：

• CreateCustomer - static，从头开始创建客户并将其添加到数据库中，
• LoadCustomer - 静态，从数据库加载Customer的实例，
• KillCustomer - 不 static，从数据库中删除客户。

如果我理解得很好，

1. LoadCustomer是进入工厂课程的好人选。
2. CreateCustomer怎么样？我想可能会被放入工厂类。是对的吗？如果没有，静态CreateCustomer方法将更改数据库状态，然后调用 CustomerFactory.LoadCustomer。恕我直言，这是一个糟糕的设计：给定的对象不必了解她自己的工厂。
3. KillCustomer在我看来对于工厂来说是一个非常糟糕的候选人：它对已经创建的对象执行，而不是创建一个。另一方面：
   • 如果非静态方法从数据库中删除了客户，则该对象（从中调用KillCustomer）仍然存在。看到一个在数据库级别上自杀但仍然保持业务水平的对象，这很奇怪。在这个级别上从工厂调用KillCustomer会更合理。例如，如果对象在应用程序中缓存，则工厂可以从数据库和缓存中删除它。
   • 在不同的类中放置创建对象的方法和删除它的方法似乎也很奇怪。 为什么工厂只能建造一些东西，而不是破坏建造的东西？

最后但并非最不重要的是，假设客户已缓存在应用程序中。 谁负责管理缓存？ IMO，工厂必须这样做：它创建对象，因此选择是否必须加载具有从数据库填充的属性的新对象，或者如果该对象已存在于缓存中。

那么，我正在考虑工厂模式的原因是什么，什么是错的？

Answer 1

工厂不是用来建造东西。当你不确切地知道你要构建什么时，它就是为了构建东西。在我看来，你所有的方法都不适合工厂。

现在，如果您在以Customer为根的继承层次结构中拥有大量不同类型的客户，并且有一些关于用于创建客户的数据的详细信息，则确定了哪种客户，那么{{ 1}}将是工厂方法的一个很好的候选人。与CreateCustomer相同，因为可能您并不完全确定数据库中存储了哪种类型的客户。

但是LoadCustomer仍然是一个糟糕的候选人。那是因为它应该只是一个虚拟方法。然后它确切地知道它被调用的客户类型。