什么时候在对象中使用工厂方法而不是factory类是一个好主意?


当前回答

我喜欢从我的类是“人”的角度来考虑设计模式,而模式是人们彼此交谈的方式。

所以,对我来说,工厂模式就像一个招聘机构。你的公司需要不同数量的工人。这个人可能知道一些他们需要雇佣的人的信息,但仅此而已。

所以,当他们需要一个新员工时,他们会打电话给招聘机构,告诉他们他们需要什么。现在,要真正雇佣一个人,你需要知道很多东西——福利,资格验证,等等。但是招聘的人不需要知道这些——招聘机构会处理所有这些。

以同样的方式,使用Factory允许使用者创建新对象,而不必知道它们是如何创建的,或者它们的依赖关系是什么——他们只需要给出他们实际需要的信息。

public interface IThingFactory
{
    Thing GetThing(string theString);
}

public class ThingFactory : IThingFactory
{
    public Thing GetThing(string theString)
    {
        return new Thing(theString, firstDependency, secondDependency);
    }
}

现在,ThingFactory的消费者可以得到一个Thing,而不需要知道Thing的依赖关系,除了来自消费者的字符串数据。

其他回答

考虑一个场景,当您必须设计Order和Customer类时。为了简单和初始需求,您不需要Order类的factory,并使用许多“new Order()”语句填充应用程序。一切都很顺利。

现在出现了一个新的需求,即Order对象不能在没有客户关联的情况下实例化(新的依赖项)。现在你有以下考虑。

1-你创建了只对新实现有效的构造函数重载。(不可接受)。 2-您更改Order()签名并更改每个调用。(这不是一个很好的练习,而且真的很痛苦)。

相反,如果你已经为Order Class创建了一个工厂,你只需要修改一行代码就可以了。我建议几乎所有聚合关联都使用Factory类。希望这能有所帮助。

GOF定义:

定义一个用于创建对象的接口,但是让子类来决定实例化哪个类。工厂方法允许类延迟实例化到子类。

一般例子:

public abstract class Factory<T> {

    public abstract T instantiate(Supplier<? extends T> supplier);

}

具体类

public class SupplierFactory<T> extends Factory<T> {

    @Override
    public T instantiate(Supplier<? extends T> supplier) {
        return supplier.get();
    }
}

实现

public class Alpha implements BaseInterface {
    @Override
    public void doAction() {
        System.out.println("The Alpha executed");
    }
}

public class Beta implements BaseInterface {
    @Override
    public void doAction() {
        System.out.println("The Beta executed");
    }
}

public interface BaseInterface {
    void doAction();
}

public class Main {
    public static void main(String[] args) {
        Factory<BaseInterface> secondFactory = new SupplierFactory<>();
        secondFactory.instantiate(Beta::new).doAction();
        secondFactory.instantiate(Alpha::new).doAction();
    }
}

短暂的优势

您正在分离可以变化的代码和不变的代码(即,使用简单工厂模式的优点仍然存在)。这种技术可以帮助您轻松地维护代码。 你的代码不是紧密耦合的;因此,你可以随时在系统中添加新的类,如Lion、Beer等,而无需修改现有的体系结构。因此,您遵循了“修改封闭,扩展开放”的原则。

我简短的解释是,当我们没有足够的信息来创建一个具体的对象时,我们使用工厂模式。我们要么不知道依赖关系,要么不知道对象的类型。我们几乎总是不知道它们因为这是运行时的信息。

示例:我们知道我们必须创建一个车辆对象,但我们不知道它是飞行还是在地面上工作。

假设你有不同的客户,他们有不同的偏好。有人需要大众、奥迪等等。有一样东西是共同的,那就是汽车。

为了让我们的客户满意,我们需要一个工厂。工厂只需要知道客户想要哪一辆车,并将其交付给客户。如果以后我们有另一辆车,我们可以很容易地扩大我们的停车场和工厂。

下面你可以看到一个例子(ABAP):

现在,我们将创建工厂的实例,并监听客户的愿望。

我们只用一个create()方法创建了三种不同的汽车。

结果:

如果你想让逻辑更清晰,程序更可扩展,工厂模式通常非常有用。

工厂类更重量级,但也有一定的优势。当您需要从多个原始数据源构建对象时,它们允许您在一个地方只封装构建逻辑(可能还包括数据的聚合)。在那里可以进行抽象的测试,而不需要考虑对象接口。

我发现这是一种有用的模式,特别是当我无法替换ORM且ORM不足,并且希望有效地实例化来自DB表连接或存储过程的许多对象时。