理解抽象工厂模式

Question

我在维基上读过关于抽象工厂模式的文章。但我不明白用这种模式能带来什么好处。你能得到一个很难避免抽象工厂模式的例子吗？考虑以下Java代码：

public abstract class FinancialToolsFactory {
    public abstract TaxProcessor createTaxProcessor();
    public abstract ShipFeeProcessor createShipFeeProcessor();
}

public abstract class ShipFeeProcessor {
    abstract void calculateShipFee(Order order);
}

public abstract class TaxProcessor {
    abstract void calculateTaxes(Order order);
}

// Factories
public class CanadaFinancialToolsFactory extends FinancialToolsFactory {
    public TaxProcessor createTaxProcessor() {
        return new CanadaTaxProcessor();
    }
    public ShipFeeProcessor createShipFeeProcessor() {
        return new CanadaShipFeeProcessor();
    }
}

public class EuropeFinancialToolsFactory extends FinancialToolsFactory {
   public TaxProcessor createTaxProcessor() {
        return new EuropeTaxProcessor();
    }
    public ShipFeeProcessor createShipFeeProcessor() {
        return new EuropeShipFeeProcessor();
    }
}

// Products
public class EuropeShipFeeProcessor extends ShipFeeProcessor {
    public void calculateShipFee(Order order) {
        // insert here Europe specific ship fee calculation
    }
}   

public class CanadaShipFeeProcessor extends ShipFeeProcessor {
    public void calculateShipFee(Order order) {
        // insert here Canada specific ship fee calculation
    }
}

public class EuropeTaxProcessor extends TaxProcessor {
    public void calculateTaxes(Order order) {
        // insert here Europe specific tax calculation
    }
}

public class CanadaTaxProcessor extends TaxProcessor {
    public void calculateTaxes(Order order) {
        // insert here Canada specific tax calculation
    }
}

如果我们只需要在代码中创建1到2次以下的代码中的对象，那么我们可以只使用新的操作符。为什么我们需要在抽象厂？

Answer 1

你错过了一半的工作:)

void processOrder(FinancialToolsFactory ftf,Order o) {

  tft.createTaxProcessor().calculateTaxes(o);
  tft.createShipFeeProcessor().calculateShipFee(o);
}

此代码的工作原理与传递FinancialToolsFactory的加拿大或欧洲实现一样好(例如，您可以将实现者类外部化到外部资源，并使用Class.newInstance()实例化)。

在这种情况下，模式使用的真正好处之一不是编写实现模式的代码，而是编写使用该代码的人！

PS:我的回答是故意不完整的，只想回答这个具体的问题；关于模式和它们的好处的讨论太大了！

Answer 2

如果要透明地支持不同的实现，则可以利用这种模式。通过将要使用哪个实现的决定委托给工厂，您的代码中只有一个点是作出该决定的(即。单一责任)。

抽象工厂模式通过聚合相关工厂，例如样本中的不同金融工具工厂，将这一概念超越了这个概念。

现在，如果您只在代码中实例化一两次金融工具，那么使用工厂就是过度工程。当您需要多次在不同的地方实例化相同接口的不同实现时，您希望能够工作，而不必担心您正在使用的是哪个实现，或者如何做出这个决定。

Answer 3

关于这个模式在网络上有相当多的资源，很难猜出用一种听起来“合理”的方式来解释它的目的的最好方法是什么。

但我认为关键是：

使用这种模式，想要创建接口特定实现的实例的人不需要知道这个特定的实现是什么。对new操作符的调用隐藏在工厂中，工厂的用户不需要知道具体的类。

这使得以后切换实现变得更容易:您不必找到并调整调用new ConcreteClass()的所有位置，并将其更改为new OtherConcreteClass()，以便使用不同的实现。您只需在周围传递一个不同的工厂，使用此工厂的每个人都会自动创建OtherConcreteClass实例(甚至不知道他这样做.)