创建者在工厂模式中的作用

是的,它很管用,但并不理想。 VehicleFactory

想象一下你有十五辆车。然后,您需要一个非常长的方法来枚举所有选项并生成正确的汽车。这不仅速度太慢,而且很容易出错,因为您可能很容易遗漏/删除某些内容,并且很难调试。一般来说,长方法的代码味道不好。

这需要您编辑 车辆工厂 Vehicle . 但是,如果您的库的用户没有访问权限,但希望从车辆继承,会发生什么?然而,通过定义摘要 车辆工厂 类,并定义自己的工厂方法。

简而言之,抽象工厂方法只是使代码更易于扩展。

此外,生成依赖于字符串的车辆是一个非常糟糕的主意;如果您使用大写字母或拼写错误怎么办?除此之外,这是相当缓慢的。最好有这样的东西。

public abstract class VehicleFactory
{
     public abstract Vehicle GetVehicle(string VehicleType)
}

public class CarFactory : VehicleFactory
{
    public override Vehicle GetVehicle(string VehicleType)
    {
          return new Car();
    }
}

public class BikeFactory : VehicleFactory
{
    public override Vehicle GetVehicle(string VehicleType)
    {
          return new Bike();
    }
}

public class ClientClass
{
    public void Main()
    {
        //Create Factories
        BikeFactory BikeFactoryObj = new BikeFactory();
        CarFactory CarFactoryObj = new CarFactory();

        //create Vehicles from factories. If wanted they can be casted to the inherited type.
        Vehicle VehicleObj=BikeFactoryObj.GetNewVehicle();
        Bike BikeObj = (Bike)BikeFactoryObj.GetVehicle();
        Car CarObj = (Car)CarFactoryObj.GetVehicle();

        //They are all inherited from Vehicle so can be used in a list of Vehicles
        List<Vehicle> Vehicles=new List<Vehicle>()
        {
             VehicleObj,
             BikeObj,
             CarObj
        }
    }
}

这里出错的机会要少得多 该类的任何用户都可以轻松地对其进行扩展。

相比之下,工厂方法在编写通用业务逻辑时非常有用,而无需指定具体受益人 哪些客户将在晚些时候写信。

一个虚构的例子(假设通用税务计算)-

public abstract class TaxComputer {
    protected abstract Calculator getCalculator();// Factory method
    public void registerIncome(){
        //...
    }
    public Amount computeTax(){
        Calculator alculator = getCalculator();
        //... Tax computation logic using abstract Calculator
        // Note: Real Calculator logic has not been written yet
        return tax;
    }
}

public interface Calculator {
    Amount add(Amount a, Amount b);
    Amount subtract(Amount a, Amount b);
    Amount multiply(Amount a, double b);
    Amount roundoff(int nearestAmount);
    // ...
}

我的所有税收规则实现都是指使用抽象计算器进行操作 数量

特定客户可以将其扩展到日元(没有小数点)或美元/英镑等的计算,甚至可以扩展到根据当地规则在每次操作后四舍五入(例如,到下一个10卢比)的计算器。

同样,USDollarTaxCalculator将用自己的操作规则对其进行扩展(但不能也不需要重新定义税务规则)

public class YenTaxComputer extends TaxComputer {
    @Override
    protected Calculator getCalculator() {
        return new YenCalculator();
    }
}

public class YenCalculator implements Calculator {
    @Override
    public Amount add(Amount a, Amount b) {
        /*Yen specific additions and rounding off*/ 
    }
    @Override
    public Amount subtract(Amount a, Amount b) {/*...*/ }
    @Override
    public Amount multiply(Amount a, double b) {/*...*/ }
    @Override
    public Amount roundoff(int nearestAmount) {/*...*/  }
}

在里面 .

客户看起来像

    public class TaxClient {
        public static void main(String[] args) {
            TaxComputer computer = new YenTaxComputer();//
            computeTax(computer);
        }
        /** A PLACE HOLDER METHOD FOR DEMO
         */
        private static void computeTax(TaxComputer computer) {
            Amount tax = computer.computeTax();
            Amount Payment = ...
            //...
        }
    }

此处需要注意的要点

1. getCalculator()
2. 创建者/工厂的具体实例可以通过静态工厂/反射等创建。可以从系统变量、平台、区域设置等方面进行选择。

如果您想阻止开发人员(或您自己)继续:

var myVehicle = new Vehicle();

相反,强制所有车辆都应该是从车辆继承的子车辆,然后将其声明为抽象车辆。

我发现以下链接非常有助于理解为工厂创建抽象类背后的逻辑,以及使用工厂模式本身的逻辑。

https://msdn.microsoft.com/en-us/library/ee817667.aspx

考虑一个模拟各种个人计算机组装的应用程序。应用程序包含一个 计算机汇编程序 类,该类负责组装计算机 对正在构建的计算机进行建模的类,以及 计算机工厂 类,该类创建计算机类的实例。在使用工厂模式时 计算机汇编程序 . 这确保了如果实例化和/或初始化过程发生变化(例如,新构造函数、激活器的使用、自定义池等),则 计算机汇编程序 根本不需要改变。这是将对象的创建从其使用中抽象出来的好处。

计算机汇编程序 直接分类 计算机工厂 类可以修改以创建新计算机类的实例(假设这个新类与计算机具有相同的接口)。此外,还可以通过创建一个新的工厂类(其接口与 计算机工厂 )这将创建新计算机类的实例(同样,具有与 ). 和以前一样,在 计算机汇编程序 类需要更改,所有的逻辑都像以前一样继续工作。这是将产品和工厂的类型抽象为不变接口的好处。

第二段指出,创造者使我们能够创建新工厂,处理产品中或其创建逻辑中可能引入的更改,迫使我们创建新工厂。