Java 现实生活中的抽象工厂设计模式

大家都知道，AbstractFactory帮助创建对象，而不需要了解创建过程。但是，当添加新工厂或在工厂类中进行大量修改时，模式的复杂性将随着时间的推移而增加。这将需要对抽象工厂创建者类进行重大更改

我曾经使用AbstractFactory，但经过我自己的修改&就像：用空接口替换抽象factory creator类，它将由factory类实现。然后将返回的对象从FactoryCreator类强制转换为我想要的真实工厂。这是有效的，但我想知道这是否打破了模式，或者这是一种不好的模式实践，或者它是否有任何缺点，会导致在未来的开发中出现同样的复杂性

下面是我从本书中获得的模式的一个非常简单的实现，以及我的修改：

形状工厂：

public interface Shape {
    void draw();
}
public class Circle implements Shape {
    @Override
    public void draw() {
        // Draw circle
    }
}
public class Rectangle implements Shape {
    @Override
    public void draw() {
        // Draw rectangle
    }
}
public class ShapeFactory implements IFactory {
    public Shape getShape(String shape) {
        if (shape.equalsIgnoreCase("CIRLE")) {
            return new Circle();
        } else if (shape.equalsIgnoreCase("RECTANGLE")) {
            return new Rectangle();
        }

        return null;
    }
}
//public class ShapeFactory extends AbstractFactory {
//    @Override
//    public Color getColor(...) {
//        //
//    }
//    @Override Shape getShape(...) {
//        //
//    }
//}

颜色工厂：

public interface Color {
    void fill();
}
public class Red implements Color {
    @Override
    public void fill() {
        // Fill red
    }
}
public class Green implements Color {
    @Override
    public void fill() {
        // Fill green
    }
}
public class ColorFactory implements IFactory {
    public Color getColor(String color) {
        if (color.equalsIgnoreCase("RED")) {
            return new Red();
        } else if (color.equalsIgnoreCase("GREEN")) {
            return new Green();
        }
    }
}
//public class ColorFactory extends AbstractFactory {
//    @Override
//    public Color getColor(...) {
//        //
//    }
//    @Override Shape getShape(...) {
//        //
//    }
//}

Factory creator界面：

public interface IFactory { }
//public abstract class AbstractFactory {
//   abstract Color getColor(String color);
//   abstract Shape getShape(String shape) ;
//}

工厂创建者：

public class FactoryCreator {
    public static IFactory getFactory(String factoryName) {
        if (factoryName.equalsIgnoreCase("SHAPE")) {
            return new ShapeFactory();
        } else if (factoryName.equalsIgnoreCase("COLOR")) {
            return new ColorFactory();
        }

        return null;
    }
}

用法：

public class demo {
    ShapeFactory shapeFactory = (ShapeFactory)FactoryCreator.getFactory("SHAPE");
    ColorFactory colorFactory = (ColorFactory)FactoryCreator.getFactory("COLOR");

    shapeFactory.getShape("CIRCLE").draw();
    shapeFactory.getShape("RECTANGLE").draw();
    colorFactory.getColor("RED").fill();
    colorFactory.getColor("GREEN").fill();
}

---

设计模式不是对正确事物的保证。。。你得先动动脑筋

历史表明，很多人对[xxx]有一定的问题，很多人可以用设计模式[yyy]解决这个问题。这就是德斯金模式的产生和定义方式

你不能说我将实现这个（或那个）模式，我无论如何都不会有问题。你必须思考，描述你的问题，看看这个模式是否能帮助你设计你的架构

显然：您的程序实现非常简单，abstractFactory的开销很大，您已经通过使用简单的接口解决了这一问题

好的，让我们来说说奥比乌斯： AbstractFactory不是您问题的解决方案：

首先：定义您的问题：我想以一种简单的方式创建参数化对象。a） 参数化的形状和颜色和b）简单的方式

可能的解决方案：factory methode（想想：你有一个界面

Shape

，有两个实现，一个界面

Color

有两个实现）

还有一家色彩厂

public ColorFactory{
    public static Color createColor(String color){
        if("GREEN".equals(color) ) // your code from above
    }
}

---

使用这些设计模式，您可以解决上面定义的问题。。。（如果您想使它更简短，您可以创建一个工厂，它为两个接口提供工厂方法）

因此，问题本质上归结为抽象类和接口之间的区别

关于这一讨论有许多来源：

关于这些模式，您需要了解的是，它们被设计成解决方案的模板。很少会出现这样的情况，即您可以复制粘贴模式而不进行任何修改，并期望完全适合您的问题

至于你的问题，你能用

FactoryCreator

接口而不是抽象类来实现

AbstractFactory

模式吗

当然可以，这是一个不会破坏模式意图的实现细节

抽象工厂提供了创建相关对象族的接口，无需显式指定它们的类

编辑

---

您将看到此模式的一个具体实现，作者在其中决定使用抽象类实现模板

根据我对上述问题的理解，一个人想要创建一个形状，然后在其中填充颜色。如果是这样的话，我们可以通过在工厂的顶部添加构建器模式来使它变得更好

class ShapeBuider
{
    private String color;

    private String shape;

    /**
     * @param color the color to set
     */
    public void setColor(String color) {
        this.color = color;
    }

    /**
     * @param shape the shape to set
     */
    public void setShape(String shape) {
        this.shape = shape;
    }

    public void build()
    {
        // create shape
        // create color
        // fill shape with color
    }

    public Object get()
    {
        // return the created object in build method here.
        return null;
    }
}

---

这种生成器方法将确保正确的颜色应用于正确的形状。

显然，与抽象工厂类相比，使用接口可以产生相同的结果。你能告诉我为什么使用抽象类而不是接口，即使使用接口会降低实现模式时的复杂性吗？你能举出这个例子所引用的书吗？@Fuhrmanator我从一本在线书中得到它：在线教程中的设计是有问题的。抽象工厂的子类只做形状或颜色，特别是当它们必须继承这两者的方法时，这没有什么意义。根据GoF，这不是抽象工厂。

class ShapeBuider
{
    private String color;

    private String shape;

    /**
     * @param color the color to set
     */
    public void setColor(String color) {
        this.color = color;
    }

    /**
     * @param shape the shape to set
     */
    public void setShape(String shape) {
        this.shape = shape;
    }

    public void build()
    {
        // create shape
        // create color
        // fill shape with color
    }

    public Object get()
    {
        // return the created object in build method here.
        return null;
    }
}