21设计模式
这是您可能看不到的东西。
@Test public void hungryHungryPatrons() {
KitchenStaff alice = new PieChef();
KitchenStaff bob = new DollopDistributor();
KitchenStaff carol = new CutleryAdder();
KitchenStaff dan = new Server();
alice.setNext(bob);
bob.setNext(carol);
carol.setNext(dan);
Patron patron = new Patron();
alice.prepare(new Pie()).forPatron(patron);
assertThat(patron, hasPie());
}
看起来很奇怪,但是这个想法很普遍。 例如,Java Servlets框架使用FilterChain
的概念来根据请求对一系列过滤器建模。
您可以使用Filter
对象对请求执行几乎所有操作。 这是一个跟踪网站访问量的网站。 请注意,完成后,它将request
和response
对象传递到链中的下一个过滤器。
public final class HitCounterFilter implements Filter {
// initialization and destruction methods go here
public void doFilter(
ServletRequest request,
ServletResponse response,
FilterChain chain)
{
int hits = getCounter().incCounter();
log(“The number of hits is ” + hits);
chain.doFilter(request, response);
}
}
我们可能会在链中使用一个对象来修改输入或输出(在这种情况下,是请求或响应):
public final class SwitchEncodingFilter implements Filter {
// initialization and destruction methods go here
public void doFilter(
ServletRequest request,
ServletResponse response,
FilterChain chain)
{
request.setEncoding(“UTF-8”);
chain.doFilter(request, response);
}
}
如果事情发展成梨形,我们甚至可能提早退出链环。
public final class AuthorizationFilter implements Filter {
// initialization and destruction methods go here
public void doFilter(
ServletRequest request,
ServletResponse response,
FilterChain chain)
{
if (!user().canAccess(request)) {
throw new AuthException(user);
}
chain.doFilter(request, response);
}
}
基本上,一旦您击中了链中的一个元素,它便拥有了完全的控制权。
在UML中,它看起来像这样:
这可能是不好的做法。
这可能有些争议,但是我要说的是,责任链模式的大多数实现都令人困惑。 因为该链依赖于每个成员正确地发挥其作用,所以很容易通过丢失一两行,在不考虑后果的情况下重新考虑链的顺序或更改ServletRequest
来简单地丢失东西(在上述情况下为HTTP请求)以使链中后面的元素不当行为的方式。
让我们更深入地研究如何从所有这些中解救一些东西。
还记得我们饥饿的顾客吗?
@Test public void
hungryHungryPatrons() {
KitchenStaff alice = new PieChef();
KitchenStaff bob = new DollopDistributor();
KitchenStaff carol = new CutleryAdder();
KitchenStaff dan = new Server();
alice.setNext(bob);
bob.setNext(carol);
carol.setNext(dan);
Patron patron = new Patron();
alice.prepare(new Pie()).forPatron(patron);
assertThat(patron, hasPie());
}
顺便说一句,该断言正在使用Hamcrest匹配器 。 如果您不太熟悉它们,请查看它们。 他们很棒。
步骤1:停止变异。
并非所有的责任链实施都涉及突变,但对于那些责任突变的实现,最好尽快消除它。 使代码不可变,可以更轻松地进行进一步重构而不会出错。
这里有三种突变情况。
- 每个工作人员后来都有“下一个”成员,而顾客本身就是变异的。 与其以后再设置下一个工作人员,不如再与下一个一起构造每个人。
- 尽管您看不到它,但
PieChef
Alice在Pie
上设置了一个标记,以将其标记为DollopDistributor
Bobcooked
了。 不用更改对象,我们让她接受UncookedPie
并将CookedPie
传递给Bob。 然后,我们让Bob接受CookedPie
。 这样可以确保我们不会接错订单,因为Bob
永远不会收到未煮熟的馅饼。 - 至于顾客,我们将从
HungryPatron
开始,让他们在进食时返回自己的新实例。@Test public void hungryHungryPatrons() { KitchenStaff dan = new Server(); KitchenStaff carol = new CutleryAdder(dan); KitchenStaff bob = new DollopDistributor(carol); KitchenStaff alice = new PieChef(bob); Patron hungryPatron = new HungryPatron(); Patron happyPatron = alice.prepare(new UncookedPie()).forPatron(hungryPatron); assertThat(happyPatron, hasPie()); }
不幸的是,这并没有太大变化。 我们为什么把馅饼送给爱丽丝仍然使顾客收到礼物,这仍然令人感到困惑,我们仍然可以按错误的顺序拿东西或要求错误的人去做。
步骤2:将其设为类型安全。
排序的部分问题是,即使爱丽丝给下一个人一个CookedPie
,我们也可以告诉她将它给任何人,从而导致ClassCastException
或同样有趣的事情。 通过参数化类型,我们可以避免这种情况,确保输入和输出类型都是正确的。
@Test public void
hungryHungryPatrons() {
KitchenStaff<WithCutlery<Meal>> dan = new Server();
KitchenStaff<Meal> carol = new CutleryAdder(dan);
KitchenStaff<CookedPie> bob = new DollopDistributor(carol);
KitchenStaff<UncookedPie> alice = new PieChef(bob);
Patron hungryPatron = new HungryPatron();
Patron happyPatron = alice.prepare(new UncookedPie()).forPatron(hungryPatron);
assertThat(happyPatron, hasPie());
}
我们的每个构造函数也会改变。 例如, PieChef
的构造函数过去看起来像这样:
public PieChef(KitchenStaff next) {
this.next = next;
}
现在,它的参数指定了它接受的类型:
public PieChef(KitchenStaff<CookedPie> next) {
this.next = next;
}
步骤3:独立的行为。
KitchenStaff
做两件事:准备食物,还把食物交给下一个人。 让我们将其分为两个不同的概念。 我们将构造一个KitchenStaff
实例,然后告诉他们谁委托给next。
@Test public void
hungryHungryPatrons() {
KitchenStaff<WithCutlery<Meal>, Serving> dan = new Server();
KitchenStaff<Meal, Serving> carol = new CutleryAdder().then(dan);
KitchenStaff<CookedPie, Serving> bob = new DollopDistributor().then(carol);
KitchenStaff<UncookedPie, Serving> alice = new PieChef().then(bob);
Patron hungryPatron = new HungryPatron();
Patron happyPatron = alice.prepare(new UncookedPie()).forPatron(hungryPatron);
assertThat(happyPatron, hasPie());
}
在这种情况下, then
不会直接修改对象,而是返回一个知道要传递该对象的KitchenStaff
的新实例。 看起来像这样:
private static interface KitchenStaff<I, O> {
O prepare(I input);
default <Next> KitchenStaff<I, Next> then(KitchenStaff<O, Next> next) {
return input -> {
O output = prepare(input);
return next.prepare(output);
};
}
}
为此,我们还必须返回一个值,而不是单纯出于副作用,以确保始终传递该值。 在我们可能不想继续的情况下,我们可以返回Optional<T>
值,该值可以包含某些内容( Optional.of(value)
)或不包含任何内容( Optional.empty()
)。
步骤4:从基础架构拆分域。
现在,我们已将KitchenStaff
与KitchenStaff
的构造KitchenStaff
,我们可以将两者分开。 alice
, bob
和朋友是可以自己了解的有用对象,将它们仅视为链的一部分是很令人困惑的。 让我们将链接留到以后。
@Test public void
hungryHungryPatrons() {
KitchenStaff<UncookedPie, CookedPie> alice = new PieChef();
KitchenStaff<CookedPie, Meal> bob = new DollopDistributor();
KitchenStaff<Meal, WithCutlery<Meal>> carol = new CutleryAdder();
KitchenStaff<WithCutlery<Meal>, Serving> dan = new Server();
KitchenStaff<UncookedPie, Serving> staff = alice.then(bob).then(carol).then(dan);
Patron hungryPatron = new HungryPatron();
Patron happyPatron = staff.prepare(new UncookedPie()).forPatron(hungryPatron);
assertThat(happyPatron, hasPie());
}
因此,现在有了一个复合对象staff
,它体现了运营链。 这使我们可以将个体作为独立实体的一部分。
步骤5:确定冗余基础架构。
在这一点上, KitchenStaff
类型看起来非常熟悉。
也许看起来像这样:
@FunctionalInterface
public interface Function<T, R> {
R apply(T t);
...
default <V> Function<T, V> andThen(Function<? super R, ? extends V> after) {
Objects.requireNonNull(after);
return (T t) -> after.apply(apply(t));
}
...
}
哦,看,这是一个功能! then
就是功能组合。 我们的KitchenStaff
类型似乎是Function
类型的一个子集,为什么不使用它呢?
@Test public void
hungryHungryPatrons() {
Function<UncookedPie, CookedPie> alice = new PieChef();
Function<CookedPie, Meal> bob = new DollopDistributor();
Function<Meal, WithCutlery<Meal>> carol = new CutleryAdder();
Function<WithCutlery<Meal>, Serving> dan = new Server();
Function<UncookedPie, Serving> staff = alice.andThen(bob).andThen(carol).andThen(dan);
Patron hungryPatron = new HungryPatron();
Patron happyPatron = staff.apply(new UncookedPie()).forPatron(hungryPatron);
assertThat(happyPatron, hasPie());
}
步骤6:(可选)将类替换为lambda和方法引用。
有时您真的不需要一堂完整的课。 在这种情况下,实现非常简单,我们可以只使用方法引用。
@Test public void
hungryHungryPatrons() {
Function<UncookedPie, CookedPie> alice = UncookedPie::cook;
Function<CookedPie, Meal> bob = CookedPie::addCream;
Function<Meal, WithCutlery<Meal>> carol = WithCutlery::new;
Function<WithCutlery<Meal>, Serving> dan = Serving::new;
Function<UncookedPie, Serving> staff = alice.andThen(bob).andThen(carol).andThen(dan);
Patron hungryPatron = new HungryPatron();
Patron happyPatron = staff.apply(new UncookedPie()).forPatron(hungryPatron);
assertThat(happyPatron, hasPie());
}
这大大减少了样板,让我们看到了实际情况。
我们的新结构与之前的示例完全不同,相差很大。
通过将业务领域(在本例中为饼图准备)与基础结构(组合功能)分离,我们可以提供更简洁的代码。 我们的行为类(专注于准备工作)消失了,只剩下了领域对象本身(例如UncookedPie
)和上面的方法(例如cook
),无论如何行为都应该存在。
21设计模式