适配器模式通过创建适配器类将不兼容接口转换为目标接口，实现方式包括对象适配器（组合）和类适配器（继承），Java中推荐使用对象适配器因其灵活性高且符合单继承特性，适用于遗留系统集成、第三方服务对接等场景，但需避免过度设计。
要在Java中实现适配器模式，核心在于创建一个“适配器”类，它负责将一个现有类的接口（称为“不兼容接口”或“被适配者”）转换成客户端期望的另一个接口（称为“目标接口”）。这通常通过让适配器实现目标接口，并在内部持有被适配者实例，然后将目标接口的方法调用委托给被适配者相应的方法来完成。简单来说，就是搭一座桥，让两个原本不匹配的接口能够协同工作。
实现适配器模式，我们通常会遇到这样一种场景：你手头有一个已经存在的类，它功能很强大，但它的方法签名或者说接口，跟你的系统里其他部分预期的完全不一样。直接改动它？不行，可能牵一发而动全身。这时候，适配器就派上用场了。
我们以一个简单的例子来说明。假设我们有一个老旧的音频播放器，它只能播放MP3格式。但现在我们的新系统需要一个能播放WAV格式的播放器接口。
首先，定义我们新系统期望的“目标接口”：
立即学习“Java免费学习笔记（深入）”；
// 目标接口：新系统期望的播放器接口
public interface MediaPlayer {
void play(String audioType, String fileName);
}然后，这是我们那个“不兼容”的、只能播放MP3的旧播放器（被适配者）：
// 被适配者：只能播放MP3的旧播放器
public class Mp3Player {
public void playMp3(String fileName) {
System.out.println("Playing MP3 file: " + fileName);
}
}现在，我们来创建“适配器”类。这个适配器需要实现
MediaPlayer接口，并且在内部持有一个
Mp3Player的实例。当
play方法被调用时，适配器会判断
audioType，如果是MP3，就委托给
Mp3Player的
playMp3方法。
// 适配器：将Mp3Player适配成MediaPlayer
public class Mp3ToWavAdapter implements MediaPlayer {
private Mp3Player mp3Player;
public Mp3ToWavAdapter(Mp3Player mp3Player) {
this.mp3Player = mp3Player;
}
@Override
public void play(String audioType, String fileName) {
if (audioType.equalsIgnoreCase("mp3")) {
mp3Player.playMp3(fileName);
} else {
// 这里可以处理其他类型，或者抛出异常
System.out.println("Invalid audio type for this adapter: " + audioType);
}
}
}最后，看看客户端如何使用这个适配器：
// 客户端代码
public class AudioPlayer {
public static void main(String[] args) {
MediaPlayer player = new Mp3ToWavAdapter(new Mp3Player());
player.play("mp3", "beyond_glory.mp3");
// 尝试播放其他类型，看看适配器如何处理
player.play("wav", "test.wav"); // 会输出 Invalid audio type...
}
}通过这个例子，我们清晰地看到了适配器如何充当中间层，让原本不兼容的
Mp3Player能够被
MediaPlayer接口所使用。这种做法，既没有修改
Mp3Player的代码，也满足了新系统的接口要求，简直是“两全其美”。
为什么适配器模式在实际项目中如此常见？
坦白说，在我的日常开发生涯中，适配器模式出现的频率真的很高。它之所以常见，我觉得主要有几个原因，而且这些原因往往是项目演进过程中不可避免的痛点。
首先，遗留系统的集成。很多时候，我们不是从零开始构建一个全新的系统，而是要在一个庞大的、已经运行多年的系统上进行迭代。这些遗留系统可能使用了过时的技术栈，或者设计理念与现代系统格格不入。它们的接口，用现在的眼光看，简直是“古董”。但你不能直接废弃它们，因为它们承载着核心业务逻辑和数据。这时候，适配器就像一座桥梁，让新旧系统能够“对话”，新系统可以通过适配器以自己熟悉的方式调用旧系统的功能，而无需深入理解旧系统的复杂性。这大大降低了集成成本和风险。
其次，第三方库或服务的整合。我们不可能所有功能都自己造轮子。引入第三方库或API是常态。但问题是，这些外部组件的设计者可不会专门为你的项目定制接口。它们有自己的接口规范，很可能与你现有系统的接口不匹配。例如，你可能需要一个日志记录器，而你用的第三方日志库接口与你系统中
ILogger接口不一致。一个简单的适配器就能解决问题，将第三方库的
log()方法映射到你系统的
writeLog()方法。我个人觉得，这比直接修改第三方库源码（通常也不允许）或者为了适配它而重构自己系统接口要明智得多。
再者，统一接口以应对多变的需求。有时候，我们可能需要处理多种类似但又不完全相同的数据源或服务。例如，一个电商平台可能需要从不同的供应商获取商品信息，每个供应商的API接口都略有差异。与其在业务逻辑层写一堆
if-else来判断是哪个供应商并调用不同的方法，不如为每个供应商创建一个适配器，将它们的接口统一到我们系统内部的一个通用商品接口。这样，业务逻辑层就可以只与这个通用接口打交道，代码会变得更干净、更易于维护和扩展。当有新的供应商加入时，只需要再写一个适配器即可，对现有代码的改动几乎没有。这种解耦的优势，在大型项目中尤为突出。
最后，它体现了一种“开闭原则”的思想——对扩展开放，对修改关闭。适配器模式允许我们引入新功能或集成新组件，而无需修改现有代码。这对于软件的长期演进和维护至关重要。我深信，一个好的设计，总能让你在面对变化时，感到从容不迫，而不是焦头烂额。
对象适配器与类适配器，我该如何选择？
在Java中实现适配器模式，我们通常会遇到两种主要形式：对象适配器和类适配器。选择哪一种，其实是基于它们各自的实现机制和Java语言的特性来决定的。
对象适配器（Object Adapter） 是我们上面例子中展示的那种。它通过组合（Composition）来实现。适配器类实现目标接口，并在内部持有一个被适配者对象的引用。当目标接口的方法被调用时，适配器会将这个调用委托给内部持有的被适配者对象。
它的优点非常明显：
- 灵活性高：适配器可以与任何实现被适配者接口的类一起工作，甚至可以适配被适配者类的子类。因为它是通过组合来关联被适配者的，所以你可以在运行时动态地切换被适配者实例。
- Java的天然优势：Java只支持单继承，但支持多实现接口。对象适配器通过实现目标接口来达到适配目的，与Java的单继承机制完美契合，不会引入额外的继承限制。
- 可以适配被适配者及其子类：因为是组合关系，所以只要被适配者类型兼容，都可以被适配。
而类适配器（Class Adapter） 则是通过继承（Inheritance）来实现的。适配器类同时继承被适配者类并实现目标接口。这意味着适配器类本身就是被适配者类型，也是目标接口类型。
类适配器的特点：
- 实现简单：在某些简单场景下，代码量可能略少一些，因为它直接继承了被适配者的行为。
- Java中的局限性：这是关键点。由于Java只支持单继承，如果你的被适配者是一个类而不是接口，那么适配器就不能再继承其他类了。这大大限制了类适配器的使用场景。如果目标接口和被适配者都是接口，那倒还好说，但实际情况往往不是这样。此外，它只能适配特定的被适配者类，无法适配其子类（除非被适配者本身是一个接口，适配器继承了实现类）。
我个人的选择倾向？ 坦白讲，在Java世界里，我几乎总是选择对象适配器。原因很简单：它的灵活性和与Java语言特性的兼容性是压倒性的优势。类适配器在Java中受限于单继承的桎梏，使得它在大多数实际场景中显得力不从心。你可能想适配一个具体的类，但你的适配器又需要继承另一个类（比如某个抽象基类），这时候类适配器就彻底没戏了。而对象适配器则完全没有这个问题。
所以，除非你遇到的场景极其特殊，被适配者是一个接口，或者你确定适配器永远不需要继承其他类，否则，请优先考虑对象适配器。它能让你少走很多弯路，代码也更健壮。
适配器模式的潜在陷阱与优化建议
虽然适配器模式是个非常实用的设计模式，但任何工具都有其两面性。在使用过程中，如果不加思考地滥用，也可能带来一些问题。
一个比较常见的“陷阱”是过度设计和复杂性增加。有时候，一个简单的接口不匹配问题，我们可能会下意识地就想到用适配器模式。但如果这个不匹配只是非常小的、局部性的差异，并且你只有一两个地方需要用到，那么直接在调用点做一些简单的转换或者封装，可能比引入一个全新的适配器类要更简洁。过多的适配器类会使得项目结构看起来很庞大，增加了类的数量，反而可能让新来的开发者感到困惑
