在 Karl Seguin 的Foundations of Programming中有一小部分是关于使用工厂模式的。他通过说明“您可以通过构造函数重载完成相同的功能”来结束段落,但没有说明何时或为什么?
那么,什么时候使用工厂模式而不是重载的构造函数来实例化一个对象更有意义呢?
在 Karl Seguin 的Foundations of Programming中有一小部分是关于使用工厂模式的。他通过说明“您可以通过构造函数重载完成相同的功能”来结束段落,但没有说明何时或为什么?
那么,什么时候使用工厂模式而不是重载的构造函数来实例化一个对象更有意义呢?
如果您想要更松散的耦合,那么工厂更有意义,因为您可以调用汽车工厂,传入 suv 枚举,然后返回正确的类。只要满足您的需要,您的应用程序并不关心实际返回了哪个类。
如果您正在执行依赖注入但需要根据需要在依赖项中创建依赖项的实例,则一种选择是将接口注入到类工厂。工厂可以返回一个接口或一个抽象类。这以一些复杂性为代价提供了灵活性、可测试性和解耦。
当我希望工厂构造几个不同的可能子类之一(并且我希望调用者知道基类但不知道子类)时,我使用工厂。
另外,有时我会使用类的静态方法而不是重载的构造函数,因为不同的静态方法采用相同的参数类型(因此不能仅根据参数类型重载构造函数)。这是一个人为的例子:
Department
{
//static factory methods
public static Department createFromBoss(string bossName) { ... }
public static Department createFromLocation(string locationName) { ... }
}
我不同意他的说法。当您有不同的构造/初始化构造函数的方法时,将使用不同的构造函数。当初始化标准导致您有不同的对象要构造时,可以使用工厂模式。
我有一种工厂有用的情况。我必须实例化一个视频效果才能在视频上运行。根据视频的类型,视频效果具有不同的具体类。
如果我实例化具体类,那么我将无法在不修改实例化代码的情况下稍后添加更多视频效果。
当我添加更多视频效果时,我只需要修改工厂来选择合适的具体类。
这有意义吗?
可能是工厂有时会生成返回类型的子类型。您不能使用构造函数来做到这一点,但可以使用工厂来灵活地做到这一点。
如果您想通过您的方法实现多态性,那么使用工厂模式来使用子类也更有意义,正如 ChrisW 所示。如果
Department b = Department.createFromBoss();
Department l = Department.createFromLocation();
然后都返回 Department 的不同子类,
b.Close()
和
l.Close()
例如,可以采取不同的操作,如果您必须通过构造函数重载尝试并关闭()单个对象,这将更加混乱。