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...}
}

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

抽象工厂模式uml

在此示例中， 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图：

抽象工厂模式功能