Adapter模式如何揭示日常小例子的深层哲理？

本文共计5271个文字，预计阅读时间需要22分钟。

在回顾问题后，我们发现前文提到一位用户拿着一个行业标准开关器（一个标准的StandardSwitcher）。这个开关器依赖于IStandardSwitchable接口才能工作，但我们的灯泡不支持这个接口。因此，目前面对的挑战是如何让这个开关器与我们的灯泡兼容。

上回问题回顾

前文说到一位用户拿着业界标准开关（一个标准的StandardSwitcher，它依赖IStandardSwitchable接口才能工作，然而目前我们的灯并不支持这个接口）出现在我面前，叫嚣着他的“标准开关”应该能打开我们的灯。好吧，这个需求是合理的，的确应该支持。但是该死的是，为什么没有早一点儿知道这个标准的存在呢？这样就不需要花费时间和人力定义这个接口，现在也不会这么纠结。和上次一样，先讲故事、演进方案，再分析背后的思想。

这回主要讲解Adapter模式，GoF讲解了这个模式是什么，怎么用，用在什么地方。我想来解释一下Adapter模式的要点是什么，对Adapter模式的延展，以及对Adapter模式的误用。顺便得瑟一下我对面向对象设计的理解。

两个方案

现在有两个选择。

1. 让我们的灯直接支持标准开关。也就是让灯实现IStandardSwitchable接口。

   • 好处：成本低，实现方式优雅。

   • 坏处：相当于放弃了已经买了我们的灯，又想用标准开关的用户。

2. 不改变现在的灯，让标准开关能打开我们的灯。标准接口我们改不了，灯也不能改。好在计算机界有句话，叫“加一层可以解决一切问题”。这让我想到了买外国电器附赠的那个电源接口转换器。现在，我们的灯需要个类似的玩意儿。

   • 好处：支持所有的灯。