适配器模式

引言

设计模式是软件工程中最重要和最实用的概念之一。它们提供了解决常见编程问题和挑战的经过验证的解决方案。其中一个最有用且广泛使用的设计模式是适配器模式。

适配器模式是一种结构型设计模式，它允许我们将一个类的接口转换为客户端期望的另一个接口。适配器允许类以兼容方式工作，这些类的接口可能不兼容。

在现实生活中，电源适配器是适配器模式的一个很好的例子。电源适配器有一个与电源插座兼容的一端，另一端则与特定设备（如笔记本电脑）兼容。适配器负责处理电压和电流的转换，使设备能够安全地使用电源。

在软件开发中，适配器模式用于解决类或模块之间接口不兼容问题。通过创建一个新的适配器类，将一个类的接口转换为另一个类可以理解和使用的接口。

适配器模式结构

举例说明

ActiveRecord

ActiveRecord 是 Ruby on Rails 框架中负责模型（MVC 架构中的 M 部分）的模块。它是一个 ORM（对象关系映射）系统，它抽象了数据库操作，并提供了一种更 Ruby 风格的方式来操作数据库。

为了使 ActiveRecord 能够与各种类型的数据库交互，Rails 使用了适配器模式。并且创建了一个 AbstractAdapter 类，这个类定义了所有数据库适配器必须实现的接口。

然后，Rails 为每种支持的数据库类型创建了具体的适配器类。这些适配器继承自 AbstractAdapter，并实现了其定义的接口。这意味着每个适配器都有相同的公共接口，但它们如何与特定类型的数据库交互可能会有所不同。

这种设计使得添加对新类型数据库的支持变得非常容易。只需创建一个新的适配器，继承自 AbstractAdapter，并实现其接口即可。这也使得测试和维护变得更简单，因为你可以针对 AbstractAdapter 的接口编写测试，而不必为每种数据库类型编写特定的测试。

PostgreSQL 和 Oracle 适配器

在定义了 AbstractAdapter 接口之后，我们可以创建特定的数据库适配器。在这个例子中，我们将创建 PostgreSQLAdapter 和 OracleAdapter。

module ActiveRecord
  module ConnectionAdapters
    class PostgreSQLAdapter < AbstractAdapter
      def select_all(sql)
        @connection.exec(sql).values
      end

      def select_one(sql)
        @connection.exec(sql).first
      end

      # ... 其他特定于 PostgreSQL 的数据库操作 ...
    end

    class OracleAdapter < AbstractAdapter
      def select_all(sql)
        @connection.exec_query(sql).to_a
      end

      def select_one(sql)
        @connection.exec_query(sql).first
      end

      # ... 其他特定于 Oracle 的数据库操作 ...
    end
  end
end

在上述代码中，我们可以看到，虽然两个适配器的接口一样（即它们都有 select_all 和 select_one 方法），但是它们如何与数据库交互却是不同的。这是因为每种数据库都有自己的 API 和 SQL 语法。

使用数据库适配器

现在我们已经定义了我们的适配器，让我们看看如何使用它们。当你创建一个新的 ActiveRecord 模型时，你可以指定要使用哪种数据库适配器：

class User < ActiveRecord::Base
  establish_connection :postgresql
end

class Product < ActiveRecord::Base
  establish_connection :oracle
end

在上述代码中，User 模型将使用 PostgreSQL 数据库，而 Product 模型将使用 Oracle 数据库。然而，不管我们使用哪种数据库，我们都可以用相同的方式查询和操作这两个模型：

users = User.where(name: 'John')
products = Product.where(name: 'Widget')

这就是适配器模式的强大之处：它允许你编写与特定技术（在本例中为数据库）无关的代码。这意味着你可以轻松地更换数据库，而无需改动大量代码。

文件读取

假设我们正在开发一个数据分析系统，需要从各种不同格式的文件（如 CSV、JSON、XML 等）中读取数据。每种文件格式都有自己独特的解析方式，但我们希望我们的应用能提供一个统一的接口来读取所有类型的文件。

首先，我们可以定义一个 FileReaderAdapter 抽象类，定义所有文件读取适配器必须实现的接口：

class FileReaderAdapter
  def initialize(filepath)
    @filepath = filepath
  end

  def read
    raise NotImplementedError, 'You must implement the read method'
  end
end

然后，我们可以为每种支持的文件类型创建一个具体的适配器类。这些适配器继承自 FileReaderAdapter 并实现其定义的接口：

require 'csv'
require 'json'
require 'nokogiri'

class CSVReaderAdapter < FileReaderAdapter
  def read
    CSV.read(@filepath)
  end
end

class JSONReaderAdapter < FileReaderAdapter
  def read
    JSON.parse(File.read(@filepath))
  end
end

class XMLReaderAdapter < FileReaderAdapter
  def read
    Nokogiri::XML(File.read(@filepath))
  end
end

现在，无论需要读取哪种类型的文件，都可以使用相同的代码来获取数据：

filepath = 'data.csv'
adapter = CSVReaderAdapter.new(filepath)
data = adapter.read

这意味着我们可以轻松地添加对新文件格式的支持，而无需改动大量代码。

这种设计也有助于保持代码的清晰和可维护。每个适配器都封装了与特定文件格式交互的复杂性，使得主应用代码更简洁，更容易理解。

音乐播放器

假设我们正在开发一个音频播放器，它需要支持各种不同格式的音频文件（如 MP3、WAV、FLAC 等）。每种音频文件格式都有自己独特的解码和播放方式，但我希望我们的应用能提供一个统一的接口来播放所有类型的音频文件。

首先，你可以定义一个 AudioPlayerAdapter 抽象类，定义所有音频播放适配器必须实现的接口：

class AudioPlayerAdapter
  def initialize(file)
    @file = file
  end

  def play
    raise NotImplementedError, 'You must implement the play method'
  end
end

然后，我们可以为每种支持的音频文件类型创建一个具体的适配器类。这些适配器继承自 AudioPlayerAdapter 并实现其定义的接口：

class MP3PlayerAdapter < AudioPlayerAdapter
  def play
    # 使用 MP3 解码库来播放文件...
    puts "Playing #{@file} as MP3"
  end
end

class WAVPlayerAdapter < AudioPlayerAdapter
  def play
    # 使用 WAV 解码库来播放文件...
    puts "Playing #{@file} as WAV"
  end
end

class FLACPlayerAdapter < AudioPlayerAdapter
  def play
    # 使用 FLAC 解码库来播放文件...
    puts "Playing #{@file} as FLAC"
  end
end

现在，无论我们需要播放哪种类型的音频文件，都可以使用相同的代码来播放：

filepath = '向天再借500年.mp3'
adapter = MP3PlayerAdapter.new(filepath)
adapter.play

适配器模式适合应用场景

当你希望使用某个类， 但是其接口与其他代码不兼容时， 可以使用适配器类。

适配器模式允许你创建一个中间层类， 其可作为代码与遗留类、 第三方类或提供怪异接口的类之间的转换器。

如果您需要复用这样一些类， 他们处于同一个继承体系， 并且他们又有了额外的一些共同的方法， 但是这些共同的方法不是所有在这一继承体系中的子类所具有的共性。

你可以扩展每个子类， 将缺少的功能添加到新的子类中。 但是， 你必须在所有新子类中重复添加这些代码， 这样会使得代码有坏味道。

将缺失功能添加到一个适配器类中是一种优雅得多的解决方案。 然后你可以将缺少功能的对象封装在适配器中， 从而动态地获取所需功能。 如要这一点正常运作， 目标类必须要有通用接口， 适配器的成员变量应当遵循该通用接口。 这种方式同装饰模式非常相似。

适配器模式优缺点

优点

• 单一职责原则你可以将接口或数据转换代码从程序主要业务逻辑中分离。
• 开闭原则。 只要客户端代码通过客户端接口与适配器进行交互， 你就能在不修改现有客户端代码的情况下在程序中添加新类型的适配器。

缺点

• 代码整体复杂度增加， 因为你需要新增一系列接口和类。 有时直接更改服务类使其与其他代码兼容会更简单。

与其他模式的关系

• 桥接模式通常会于开发前期进行设计， 使你能够将程序的各个部分独立开来以便开发。 另一方面， 适配器模式通常在已有程序中使用， 让相互不兼容的类能很好地合作。
• 适配器可以对已有对象的接口进行修改， 装饰模式则能在不改变对象接口的前提下强化对象功能。 此外， 装饰还支持递归组合， 适配器则无法实现。
• 适配器能为被封装对象提供不同的接口， 代理模式能为对象提供相同的接口， 装饰则能为对象提供加强的接口。
• 外观模式为现有对象定义了一个新接口， 适配器则会试图运用已有的接口。 适配器通常只封装一个对象， 外观通常会作用于整个对象子系统上。
• 桥接、 状态模式和策略模式 （在某种程度上包括适配器） 模式的接口非常相似。 实际上， 它们都基于组合模式——即将工作委派给其他对象， 不过也各自解决了不同的问题。 模式并不只是以特定方式组织代码的配方， 你还可以使用它们来和其他开发者讨论模式所解决的问题。

总结

适配器模式是一种非常有用的设计模式，尤其是在我们需要使两个不兼容的接口能够一起工作的时候。

在 ActiveRecord 的例子中，适配器模式被用来处理与不同类型数据库的交互。每种数据库（如 PostgreSQL、Oracle、SQLite 等）都有其特定的接口和行为，而 ActiveRecord 使用适配器模式提供了一个统一的接口来进行数据库操作。这使得开发者可以在不考虑底层数据库细节的情况下编写代码，极大地提高了代码的可维护性和可扩展性。

在文件系统的例子中，适配器模式被用来读取不同格式的文件（如 CSV、JSON、XML 等）。由于每种文件格式都有其独特的解析方式，我们使用适配器模式为每种文件格式提供了一个统一的读取接口。这使得主应用代码更简洁、更易理解，并且可以轻松地添加对新文件格式的支持。

在音乐播放器的例子中，适配器模式被用来播放不同格式的音频文件（如 MP3、WAV、FLAC 等）。每种音频格式都有其独特的解码和播放方式，而我们使用适配器模式为每种音频格式提供了一个统一的播放接口。这使得音乐播放器可以轻松地添加对新音频格式的支持，同时保持代码的清晰和可维护。