Design patterns 工厂法图形实体

工厂法是否只遵循实体中的依赖倒置原则和界面分离原则？我在另一个网站上发现了这一点，但找不到任何理由说明它为什么要实现接口隔离原则。它遵循DIP，因为它依赖于interfaceabstraction而不是具体的类。

首先，工厂方法是一种独立的设计模式，用于创建对象，而无需向客户机公开实例化逻辑。factory方法不遵循任何原则，但它旨在将对象创建的责任分离给不同的类，以处理创建对象的问题，而不必指定要创建的对象的确切类。因为它是一种创建模式，所以它的职责就是创建对象。它也与界面分离原则无关。接口分离原则主要关注的是不创建胖接口，而是使其精简，并以这样一种方式进行逻辑分组，即不应强制任何客户机实现它不需要的方法

---

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

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

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

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

应用Factory方法设计模式时，组件之间的依赖关系为：

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

---

因此，组件之间的依赖关系现在被有效地颠倒了。在前一种情况下，客户机组件必须在任何一个可构造组件发生更改时进行更改。在以后的版本中，客户端组件可以在其他地方重复使用，并且每当IConstructable更改时，可构造*组件都必须更改。

我不确定我是否理解了这个问题，请详细说明。工厂方法在实体中是否只遵循依赖性反转原则和界面分离原则，这似乎不太令人困惑？最后，它跟随DIP，因为它依赖于一个界面而不是具体的类。我在另一个网站的链接上发现了这一点，这样我们就可以自己阅读了。这个答案似乎自相矛盾。首先，工厂法没有遵循任何原则；但第二，设计模式有助于实现坚实的原则。那么图案是否遵循原则？@jaco0646设计图案不等于实体原则。但在某些情况下，设计模式将有助于实现坚实的原则。这并不意味着设计模式是可靠的原则。设计模式背后的主要思想是解决面向对象的问题。我够清楚了吗？