我们什么时候需要适配器模式？

Question

我们什么时候需要采用适配器模式？如果可能的话，请给我一个适合该模式的现实世界示例。

Answer 1

我开发了一个需要与外部 DVR 接口的系统。大多数情况下，所有 DVR 都具有相同的基本功能：从某个视频源开始录制；停止录音；从某个时间开始播放； 每个 DVR 制造商都提供了一个软件库，允许我们编写代码来

控制他们的设备（为了讨论起见，我将其称为 SDK）。尽管每个 SDK 都提供了所有基本功能的 API，但它们都不完全相同。这是一个非常粗略的示例，但您明白了：

• BeginPlayback(DateTime startTime);
• 开始播放（长startTimeTicks）；
• 播放（字符串开始日期，字符串开始时间）；

我们的软件需要能够与所有 DVR 交互。因此，我们没有为每个不同的 SDK 编写可怕的 switch/case，而是创建了自己的通用 IDVRController 接口，并将所有系统代码写入该接口：

• Playback(DateTime startTime);

然后，我们为每个 SDK 编写了不同的适配器实现，所有这些都实现了我们的 IDVRController 接口。我们使用配置文件来指定系统将连接到的 DVR 类型，并使用工厂模式来实例化该 DVR 的 IDVRController 的正确实现者。

这样，适配器模式使我们的系统代码变得更简单：我们总是编码到 IDVRController。它允许我们在部署后推出新 SDK 的适配器（我们的工厂使用反射来实例化正确的 IDVRController 实例）。

Answer 2

现有接口

interface Shape {
    public int calculateArea(int r);
}

Shape 接口的当前实现

class Square implements Shape {
    @Override
    public int calculateArea(int r) {
        return r * r;
    }
}

现在考虑一下您希望 Circle 类适应我们无法修改的现有接口（由第三方编写）。

class Circle {
    public double calculateCircularArea (int r) {
        return 3.14 * r * r;
    }
}

现在我们已经将 Circle 实现适应了我们的 Shape 接口。因此我们需要一个适配器，因为它们不兼容。

class CircleAdaptor extends Circle implements Shape {
    @Override
    public int calculateArea(int r) {
        return (int) calculateCircularArea(r);
    }
}

CircleAdaptor - 是 Circle 的适配器；
圆圈 - 是适应者；
形状 - 是目标界面。

public class AdapterPattern {
    public static void main(String[] args) {
        Shape circle = new CirCleAdaptor();
        System.out.println("Circle Area " + circle.calculateArea(5));
        Shape square = new Square();
        System.out.println("Square Area " + square.calculateArea(5));
    }
}

希望这可以让您更好地了解何时使用它。
另请参阅什么是装饰器模式？

Answer 3

在计算机编程中，适配器
模式（通常称为
包装模式或简单的包装）
是一种翻译的设计模式
一个类的一个接口
兼容的接口。适配器一个
允许班级一起工作
通常不能因为
不兼容的接口，通过提供
使用时与客户端的接口
原来的界面。适配器
将对其接口的调用转换为
调用原始接口，以及
所需执行的代码量
这通常很小。适配器
还负责改造
数据转化为适当的形式。为了
例如，如果有多个布尔值
存储为单个整数，但是
您的消费者需要
'true'/'false'，适配器将是
负责提取
整数中的适当值
值。

维基百科！！！

Answer 4

当您必须处理具有相似行为的不同接口（这通常意味着具有相似行为但具有不同方法的类）时，可以使用适配器设计模式。例如，一个类连接到三星电视，另一个类连接到索尼电视。它们将共享常见的行为，例如打开菜单、开始播放、连接到网络等，但每个库都会有不同的实现（具有不同的方法名称和签名）。这些不同供应商特定的实现在 UML 图中称为Adaptee。

因此，在您的代码（在 UML 图中称为 Client）中，您可以创建一个通用接口，而不是对每个供应商（或 Adaptee）的方法调用进行硬编码（在 UML 图中称为 Target）来包装这些类似的行为并仅使用一种类型的对象。

然后适配器将实现目标接口，将其方法调用委托给通过适配器传递给适配器的Adaptees构造函数。

为了让您在 Java 代码中实现这一点，我使用与上面提到的完全相同的示例编写了一个非常简单的项目，使用适配器来处理多个智能电视接口。该代码很小，文档齐全且不言自明，因此请深入研究它以了解现实世界的实现是什么样子。

只需下载代码并将其作为 Maven 项目导入 Eclipse（或您最喜欢的 IDE）即可。您可以通过运行org.example.Main.java来执行代码。请记住，这里重要的是了解如何将类和接口组装在一起来设计模式。我还在com.thirdparty.libs包中创建了一些假的Adaptees。希望有帮助！

https://github.com/Dannemann/java-design-patterns

Answer 5

在以下场景中需要适配器模式：

定义了接口 I1

假设您已经使用方法 M1 和 M2 C1 ，并且C2 实现此接口 I1，现在用于 C1，同时实现 M1 和 M2 您没有找到其他现有类的帮助，因此您需要自己编写所有逻辑。

现在，在实现类C2时，您遇到了类C3，其方法M3和M4可用于实现M1 和 M2 用于 C2，以便在类 M3 和 M4 中使用这些 M3 和 M4 code>C2 扩展类 C3 并使用 C3 的 M3 和 M4。

在此示例中，C2 变为 Adapter 类，C3 变为 adaptee

package com.design.patterns;

public class AdapterExample {
    public static void main(String[] args) {
        Shape line = new LineShape();
        line.draw();

        Shape text = new TextShape();
        text.draw();
    }
}

//==Start from here
interface Shape{
    public void draw();
}

class LineShape implements Shape{
    @Override
    public void draw() {
        System.out.println("write some logic and draw line");
    }   
}

//Adapter
class TextShape extends TextView implements Shape{
    @Override
    public void draw() {
        System.out.println("logic is already there in class TextView");
        drawText();
    }   
}

// Adaptee
class TextView{
    public void drawText() {
        System.out.println("Drawing Text Shape");
    }
}

Answer 6

不兼容的接口

EuroPlug 连接器仅连接到欧洲电源插座：

interface EuroPlug {
   fun plugIn()
}

class EuroSocket {
   fun supplyCurrent(plug: EuroPlug) = plug.plugIn()
}

USPlug 连接器仅连接到美国电源插座：

interface USPlug {
   fun plugIn()
}

class USSocket {
   fun supplyCurrent(plug: USPlug) = plug.plugIn()
}

---

创建适配器

当我们有 USSocket 和 < code>EuroPlug，我们创建一个适配器将 EuroPlug 转换为 USPlug：

class EuroToUSPlugAdapter(private val euroPlug: EuroPlug) : USPlug {
   override fun plugIn() = euroPlug.plugIn()
}

现在 EuroToUSPlugAdapter 适配接口 USPlug< /code> 已经存在的类 USSocket 而不对其进行更改。

---

使用适配器

这里我们有一个 USSocket 但有一个 EuroPlug 对象。因此，我们将 EuroPlug 对象传递给 EuroToUSPlugAdapter，它负责将 EuroPlug 转换为 USPlug：

fun main() {
   val usSocket = USSocket()
   val euroPlug = object : EuroPlug {
       override fun plugIn() {
           println("Euro plug adapted for US Socket")
       }
   }
  
   val euroAdapter = EuroToUSPlugAdapter(euroPlug)
   usSocket.supplyCurrent(euroAdapter)
}

---

就是这样！这就是适配器模式允许两个不兼容的接口一起工作的方式。希望有帮助。

Answer 7

适配器模式的一个非常常见的示例是通过服务提供者接口< /a> 并且在很多 Java EE 框架中常用。

其原因是允许 Java EE 的不同实现，但程序员只需根据 Java EE 规范进行编码，而不是特定于实现的内容。

与直接使用 WebSphere 类进行编码之类的东西相反，这会限制您使用 WebSphere。

或者更糟糕（根据我的经验），Apache HTTP Client 并后来发现，因为您编码为该实现而不是正常的 HttpUrlConnection，所以您必须进行大量重新编码，因为它不支持当前版本的 TLS，这将是如果原始开发人员编码为更稳定的 API，而我们只需要升级 Java 运行时，就可以避免这种情况。

Answer 8

摘自：Alexey Soshin 的书《Kotlin 设计模式与最佳实践第二版》：

Adapter 设计模式的主要目标是将一个接口转换为
另一个界面。在物理世界中，这个想法的最好例子是
可以是电源插头适配器或USB 适配器。
想象一下你深夜在酒店房间里，电池电量还剩 7%
你的手机。您的手机充电器落在办公室另一端
城市。您只有一个欧盟插头充电器和迷你 USB 数据线。但你的
手机使用USB-C，因为您必须升级。你在纽约，所以所有
您的插座（当然）是 USB-A。那么，你做什么呢？哦，这很容易。你
在半夜寻找一个迷你 USB 转 USB-C 适配器并希望
您还记得带上欧盟至美国插头适配器。
电量仅剩 5% – 时间不多了！
那么，既然我们了解了适配器在物理世界中的用途，那么让我们
看看我们如何在代码中应用相同的原则。
让我们从接口开始。
USPlug 假定电源为 Int。如果它有幂，它的值就是 1
任何其他值（如果没有）：

interface USPlug {
 val hasPower: Int
}

EUPlug 将电源视为字符串，为 TRUE 或 FALSE：

interface EUPlug {
 val hasPower: String // "TRUE" or "FALSE"
}

对于 UsbMini，电源是一个枚举：

interface UsbMini {
 val hasPower: Power
}
enum class Power {
 TRUE, FALSE
}

最后，对于 UsbTypeC，功率是一个布尔值：

interface UsbTypeC {
 val hasPower: Boolean
}

我们的目标是将美国电源插座的功率值带到我们的
手机，将由此函数表示：

fun cellPhone(chargeCable: UsbTypeC) {
 if (chargeCable.hasPower) {
 println("I've Got The Power!")
 } else {
 println("No power")
 }
}

让我们首先在代码中声明美国电源插座的外观。它
将是一个返回 USPlug 的函数：

// Power outlet exposes USPlug interface
fun usPowerOutlet(): USPlug {
 return object : USPlug {
 override val hasPower = 1
 }
}

我们的充电器将是一个将 EUPlug 作为输入和输出的函数
UsbMini：

// Charger accepts EUPlug interface and exposes UsbMini
// interface
fun charger(plug: EUPlug): UsbMini {
 return object : UsbMini {
 override val hasPower=Power.valueOf(plug.hasPower)
 }
}

接下来，让我们尝试将我们的手机、充电器和usPowerOutlet结合起来
函数：

cellPhone(
 // Type mismatch: inferred type is UsbMini but // UsbTypeC
was expected
 charger(
 // Type mismatch: inferred type is USPlug but //
EUPlug was expected
 usPowerOutlet()
 )
)

如您所见，我们遇到了两种不同类型的错误 - 适配器设计
模式应该可以帮助我们解决这些问题。
调整现有代码
我们需要两种类型的适配器：一种用于电源插头，另一种用于电源插头
我们的 USB 端口。
我们可以通过定义以下内容来使美国插头与欧盟插头配合使用
以下扩展功能：

fun USPlug.toEUPlug(): EUPlug {
 val hasPower = if (this.hasPower == 1) "TRUE" else
 "FALSE"
 return object : EUPlug {
 // Transfer power
 override val hasPower = hasPower
 }
}

我们可以在Mini USB和USB-C实例之间创建一个USB适配器
以类似的方式：

fun UsbMini.toUsbTypeC(): UsbTypeC {
 val hasPower = this.hasPower == Power.TRUE
 return object : UsbTypeC {
 override val hasPower = hasPower
 }
}

最后，我们可以通过组合所有这些适配器再次重新上线
一起：

cellPhone(
 charger(
 usPowerOutlet().toEUPlug()
 ).toUsbTypeC()
)

适配器设计模式比其他设计更简单
模式，你会看到它被广泛使用。现在，让我们更详细地讨论它在现实世界中的一些用途。

现实世界中的适配器

您可能遇到过适配器设计模式的许多用途
已经。这些通常用于适应概念和
实施。例如，让我们采用JVM集合的概念
与 JVM 流的概念不同。
列表是可以使用 listOf() 创建的元素集合
功能：

val list = listOf("a", "b", "c")

流是元素的惰性集合。你不能简单地通过
收集到接收流的函数，即使它可能会使
sense:

fun printStream(stream: Stream<String>) {
 stream.forEach(e -> println(e))
}

printStream(list) // Doesn't compile

幸运的是，集合为我们提供了 .stream() 适配器方法：

printStream(list.stream()) // Adapted successfully

许多其他 Kotlin 对象都有适配器方法，通常以 to 开头
作为前缀。例如，toTypedArray() 将列表转换为数组。

使用适配器的注意事项

您是否曾经将 110 V 美国电器插入 220 V EU 插座
通过适配器，然后完全炸了？
如果您不小心，您的代码也可能会发生这种情况。
以下示例使用另一个适配器，它也可以很好地编译：

val stream = Stream.generate { 42 }
stream.toList()

但它永远不会完成，因为 Stream.generate() 生成无限列表
整数。因此，请小心并明智地采用这种设计模式。

Answer 9

我在 Bharath Thippireddy 设计模式课程中找到了最清晰、最真实的例子。
我们有 WeatherUI 类，它通过邮政编码查找温度，我们有 WeatherFinderImpl 类，它通过城市名称了解温度，因此我们需要创建 WeatherAdapter > 类将获取邮政编码，将其更改为城市名称并调用 WeatherFinder 类以返回正确的温度。
WeatherUi 类：

public class WeatherUI {
    public void showTemperature(int zipcode) {
        //I just have zipcode
    }
}

和 WeatherFinder 接口：

public interface WeatherFinder {
    int find(String city);
}

以及只能通过城市名称查找温度的 WeatherFinderImpl：

public class WeatherFinderImpl implements WeatherFinder{
    @Override
    public int find(String city) {
        return 25;
    }
}

在 WeatherUI 类我们可以创建一个将邮政编码转换为城市的方法，或者我们可以创建一个新的 adapter 类：

public class WeatherAdapter {
    public int findTemperature(int zipcode){
        String city = null;
        
        //here most probably we would take it from db, in example hardcode is enough
        if(zipcode == 63400){ 
            city = "Ostrow Wielkopolski";
        }

        WeatherFinder finder = new WeatherFinderImpl();
        int temperature = finder.find(city);
        return temperature;
    }
}

并在 WeatherUI 中调用它：

public class WeatherUI {
    public void showTemperature(int zipcode) {
        WeatherAdapter adapter = new WeatherAdapter();
        System.out.println(adapter.findTemperature(63400));
    }
}

测试它很简单：

    public static void main(String[] args) {
        WeatherUI ui = new WeatherUI();
        ui.showTemperature(63400);
    }