1

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

假设我有一个Customer基本上具有以下方法的类：

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

如果我理解得很好，

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

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

那么，在我对工厂模式的思考中，什么是对的，什么是错的？

4

1 回答 1

3

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

现在，如果你有一大堆不同类型的客户在一个根植于继承层次结构中，Customer并且有关用于创建客户的数据的一些细节确定了哪种客户，那么CreateCustomer将是工厂方法的一个很好的候选者。与此相同，LoadCustomer因为大概您不完全确定数据库中存储了哪种客户。

但KillCustomer仍然是一个糟糕的候选人。那是因为它应该只是一个虚拟方法。然后它确切地知道它被叫到了哪种类型的客户。

于 2010-09-04T09:24:59.583 回答