工厂方法模式实体

Question

Factory方法是否只遵循实体中的依赖反转原则和界面分离原则？我在另一个网站上发现了这一点，但找不到任何理由来解释为什么它实现了接口隔离原则。它遵循DIP，因为它依赖于接口(抽象)而不是具体类。

Answer 1

首先，工厂方法是一种独立的设计模式，用于创建对象，而无需向客户端公开实例化逻辑。工厂方法不遵循任何原则，但它的目的是将创建对象的责任分离到不同的类，以处理创建对象的问题，而不必指定要创建的对象的确切类。因为它是一个创建模式，所以它的职责就是创建对象。这也与接口分离原则无关。接口分离原则主要关注的是不创建胖接口，而是使它变得精益，并以一种逻辑上的方式分组，这样任何客户端都不应该被强迫实现它不需要的方法。

请不要混淆可靠的原则和设计模式。可靠的原则只是实现代码整洁的一组原则。很少有设计模式有助于实现可靠的原则。例如，您将对象创建的责任转移到工厂，那么工厂的全部责任将是对象创建(单一责任原则)等等。

Answer 2

在没有其他接口的情况下，您不能确认工厂方法模式本身是否遵循接口分离原则。该原则本质上意味着一个类最有可能使用另一个类的整个接口，因此，如果工厂只提供一两个方法来构造客户端要使用的实例(这与本例中的单一责任原则紧密相关)，那么它们可能会遵循该原则。然而，这并不意味着客户端将遵循这一原则。

至于依赖反转原则，如果您比较使用和不使用此模式的设计，则很容易识别。如果没有FM模式，客户端必须决定实例化和使用可构造对象的哪个子类型。因此，这些将是依赖项(用括号分隔的单独组件；箭头方向表示“依赖于”)：

(Client) -+-> (ConstructableA)
          \-> (ConstructableB)

应用Factory Method设计模式时，组件之间的从属关系为：

(Client -> IConstructable) <-+- (ConstructableA)
                             \- (ConstructableB)

因此，实际上，组件之间的依赖关系现在颠倒了。在前一种情况下，客户端组件必须(很可能)在任何一个可构造组件发生更改时进行更改。在后一种情况下，客户端组件可以在其他地方重用，并且每当IConstructable更改时，可构造的*组件都必须更改。