设计模式适配器模式

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

适配器模式桥接世界。 在一个世界中，我们有一个概念的界面。 在另一个世界，我们有不同的界面。 这两个接口有不同的用途，但有时我们需要进行转移。 在编写良好的世界中，我们可以使用适配器使遵循一种协议的对象遵守另一种协议。

适配器模式有两种。 我们不会谈论这个：

interface Fire {<T> Burnt<T> burn(T thing);
}interface Oven {Food cook(Food food);
}class WoodFire implements Fire { ... }class MakeshiftOven extends WoodFire implements Oven {@Override public Food cook(Food food) {Burnt<Food> noms = burn(food);return noms.scrapeOffBurntBits();}
}

这种形式（ 类Adapter模式）使我感到惊讶，因为extends给了我暴走的吉卜赛人。 为什么不在本文的讨论范围之内？ 随时问我，我会很乐意谈论你的耳朵（可能是你的鼻子）。

取而代之的是让我们谈论对象适配器模式 ，该模式通常被认为在所有方面都更加有用和灵活。

让我们看一下同一个类，遵循以下替代方法：

class MakeshiftOven implements Oven {private final Fire fire;public MakeshiftOven(Fire fire) {this.fire = fire;}@Override public Food cook(Food food) {Burnt<Food> noms = fire.burn(food);return noms.scrapeOffBurntBits();}
}

我们将像这样使用它：

Oven oven = new MakeshiftOven(fire);
Food bakedPie = oven.cook(pie);

该模式通常遵循以下简单结构：

很好，对吗？

是。 有点。 我们可以做得更好。

我们已经有对Fire的引用，因此构造另一个仅用于Fire对象似乎有点…过大。 该对象实现了Oven 。 其中有一个抽象方法 。 我在这里看到一种趋势。

相反，我们可以创建一个功能相同的函数。

Oven oven = food -> fire.burn(food).scrapeOffBurntBits();
Food bakedPie = oven.cook(pie);

我们可以再进一步编写方法引用，但是实际上情况变得更糟。

// Do *not* do this.
Function<Food, Burnt<Food>> burn = fire::burn;
Function<Food, Food> cook = burn.andThen(Burnt::scrapeOffBurntBits);
Oven oven = cook::apply;
Food bakedPie = oven.cook(pie);

这是因为Java不能在功能接口之间进行隐式转换，因此我们需要为它提供有关操作的每个阶段的提示。 另一方面，Lambda对于任何具有正确类型的功能接口都是隐式强制的，并且编译器在弄清楚如何做到这一点方面做得很好。

我们新的UML图将如下所示：

通常，我们真正需要的只是方法参考。 例如，使用Executor界面。

package java.util.concurrent;/*** An object that executes submitted {@link Runnable} tasks.*/
public interface Executor {void execute(Runnable command);
}

它消耗了Runnable对象，这是一个非常有用的界面。

现在，我们将其中一个和一堆Runnable任务保存在Stream 。

Executor executor = ...;
Stream<Runnable> tasks = ...;

我们如何在执行Executor上执行所有这些Executor ？

这行不通：

tasks.forEach(executor);

事实证明， Stream 上的forEach方法确实需要使用方，但是它是一个非常特定的类型：

public interface Stream<T> {...void forEach(Consumer<? super T> action);...
}

Consumer看起来像这样：

@FunctionalInterface
public interface Consumer<T>
{void accept(T t);...
}

乍一看，这似乎没有什么帮助。 但是请注意， Consumer是一个功能接口，因此我们可以使用lambda真正轻松地指定它们。 这意味着我们可以这样做：

tasks.forEach(task -> executor.execute(task));

对此可以进一步简化：

tasks.forEach(executor::execute);

Java 8使适配器变得非常简单，以至于我犹豫不再将它们称为模式。 这个概念仍然非常重要。 通过显式创建适配器，我们可以将这两个世界分开，除了在定义的边界点处。 的实现，但是？ 它们只是功能。

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

设计模式适配器模式