抽象工厂模式设计模式
这是我的演讲的第二部分,“ 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);
}
哦,看,这是一个功能。
这种轻率的情况在“抽象工厂”模式以及许多其他模式中非常普遍。 尽管它们大多数都提供了许多离散的功能,并提供了许多方法,但是出于灵活性的考虑,或者由于我们只需要一件事情,我们经常倾向于将它们分解为单方法类型。时间。
那么我们将如何实现这种糕点制造商呢?
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
抽象工厂模式设计模式