21世纪的设计模式：抽象工厂模式

这是我的演讲的第二部分，“ 21世纪的设计模式” 。

此模式在Java代码中到处都有使用，尤其是在更多“企业”代码库中。 它涉及一个接口和一个实现。 该界面如下所示：

public interface Bakery {
    Pastry bakePastry(Topping topping);
    Cake bakeCake();
}

并执行：

public class DanishBakery implements Bakery {
    @Override public Pastry bakePastry(Topping topping) {
        return new DanishPastry(topping);
    }

    @Override public Cake bakeCake() {
        return new Aeblekage(); // mmmm, apple cake...
    }
}

更一般而言，抽象工厂模式通常是根据此结构实现的。

在此示例中， Pastry和Cake是“抽象产品”，而Bakery是“抽象工厂”。 它们的实现是具体的变体。

现在，这是一个相当普通的示例。

实际上，大多数工厂只有一种“创建”方法。

@FunctionalInterface
public interface Bakery {
    Pastry bakePastry(Topping topping);
}

哦，看，这是一个功能。

这种轻率的情况在Abstract Factory模式以及其他许多情况中非常普遍。 尽管它们大多数都提供了许多离散的功能，并提供了许多方法，但是出于灵活性的考虑，或者由于我们只需要一件事情，我们常常倾向于将它们分解为单方法类型。时间。

那么我们将如何实现这种糕点制造商呢？

public class DanishBakery implements Bakery {
    @Override public Pastry apply(Topping topping) {
        return new DanishPastry(Topping topping);
    }
}

好的，那很容易。 它看起来像早期的DanishBakery但是不能做蛋糕。 美味的苹果蛋糕……有什么意义？

好吧，如果您还记得的话， Bakery有一种单一的抽象方法 。 这意味着它是一个功能接口 。

那么，此功能等效于什么？

Bakery danishBakery = topping -> new DanishPastry(topping);

甚至：

Bakery danishBakery = DanishPastry::new;

瞧 我们的DanishBakery课程已经结束。

但是我们可以走得更远。

package java.util.function;
/**
 * Represents a function that
 * accepts one argument and produces a result.
 *
 * @since 1.8
 */
@FunctionalInterface
public interface Function<T, R> {
    /**
     * Applies this function to the given argument.
     */
    R apply(T t);

    ...
}

我们可以用Function<Topping, Pastry>代替Bakery ； 它们具有相同的类型。

Function<Topping, Pastry> danishBakery = DanishPastry::new;

在这种情况下，我们可能要保留它，因为它的名称与我们的业务相关，但通常，类似Factory的对象没有真正的领域用途，只能帮助我们解耦代码。 （ UserServiceFactory ，有人吗？）这很棒，但是在这些情况下，我们不需要显式的类-Java 8内置了一堆接口，例如Function ， Supplier和java.util.function更多接口。包装，非常适合我们的需求。

这是我们更新的UML图：

aa 好多了。

翻译自: https://www.javacodegeeks.com/2015/04/design-patterns-in-the-21st-century-the-abstract-factory-pattern.html