面试总结---适配器模式

这就需要发帖人将投票 适配为 对发帖的建议，当然这比较难！必须坚持下面的原则
（1）群众的眼睛是雪亮的。如对次条怀疑，参考第二点
（2）群众的眼睛是雪亮的，但有时候鼠标不好使。

这些设计模式只是为了解决一些具体问题的通用方法而已， 思想对了应该就可以了吧

我感觉也是这样的，像这个模式从字面上还是比较好理解的。最简单咱们常用的笔记本的电源上面一般都标有(AC　Adapter)。　关键字"适配"! 思想通了，就会问具体的应用实例，还要是工作中的。当然不能没有的说有，就要说出在工作中遇到的这个基于事件的缺省适配器。被鄙视了。说这个不是适配器模式。如果真的不对，至少不是我一个人不对，我不是一个人在战斗。


Java与模式 第22章 适配器（Adapter）模式
阎宏，美籍华人。1992年获博士学位，翌年赴日本京都大学进行博士后研究工作。 曾在美国花旗银行（Citibank）、汤臣金融（Thomson Financial）、奥本海默基金（Oppenheimer）等处担任软件开发、架构设计和技术管理等工作。

这哥们儿也悲剧了。。看这章节  也真2！！

我没有恶意，说实话我也讨厌这种装X的面试官。。。。

就事论事吧。

我查了一下GOF（四人帮）的书，作者是Steven John Metsker，仍然没有发现所谓的缺省适配器。里面有这一句：

The MouseAdapter class, as Figure 3.9 shows, is another example of a class that stubs out
the requirements of a registration interface.
（MouseAdapter 类，如3.9所示，是另一个熄灭接口需求的类的例子---我是直译的，呵呵。上文举了一个看似适配器，实际上不是适配器的例子。 在例子最后作者这么写：In fact, although the word adapter appears in the name of the MessageAdapter class, you might question whether MessageAdapter is an
instance of the ADAPTER pattern. 大致意思就是说虽然类名里有adapter这个词，但值得怀疑它是否是适配器模式。 因此我个人觉得作者的意思是说MouseAdapter这个类不应该看做适配器模式。但是作者没有这么绝对，紧接着提了一个具有挑战性的问题：Provide an argument that you are applying the
ADAPTER pattern when you use the
MouseAdapter class. Alternatively, argue that this
is not the case.

综上所述，我觉得MouseAdapter 这个类不能作为adapter模式的一个例子

http://en.wikipedia.org/wiki/Adapter_pattern#A_further_form_of_runtime_Adapter_pattern
这是维基百科对adapter的解释， 就看一下目录就好了，有object adapter, class adapter 还有一个叫做A further form of runtime Adapter pattern 这三种，仍然没有缺省适配器模式额。。

我觉得，如果你能快速识别什么事适配器模式，什么不是适配器模式的话，对你的提高很大。我以前看过设计模式的书，觉得这个适配器模式是最简单的了，基本上没有怎么看。但是为了回答楼主的问题我又回头看了看，这才发现这个模式还是有很多东西要注意的。

对你的执着，表示敬佩。  我认为 GOF首先提出了设计模式这个概念，并列举了相关的23种模式，并给出了定义，应用场合，等，并得到大多数从业人员认可。

所以如果要严格按数学逻辑进行 辨别一个模式是否是适配器模式, 有必要看看Gof所讲的适配器模式。 GOF所定义的适配器模式，从需求，应用场景，技术实现几个方面进行了描述。如果，应用场景与实现这该定义的必要条件，那么所谓的缺省适配器模式，将不是GOF所说的适配器模式。因为GOF所说的适配器模式，是需要把一个类的实例，注入到另一个类的实例中去。而缺省适配器模式，实现的关键是采用了类继承特性。这与GOF适配器模式中的 UML图有着本质的相差。GOF只列举了二十多种设计模式，但是现实生活中何止二十三种，所以在这里要像数学一样辨识模式，在学习模式能加深理解，没有多大的用处。 关键时，能领会二十三种场景，能从二十种应用场景与技术实现，得到最核心最本质的东西，并应用到自已的开发中去，这最为重要。至于交流，还是UML图或其他约定的工具，最为方便。

我认为，软件教学界，应该把GOF二十三种模式本后更细微的更简单基本的实现方式，结合需求，进行讲解，指导软件人员面临具体设计任务时，何时利用对象注入，何时利用工厂生成类实例，何时利用类继承，何时利用模板技术等。 在这个过程中，能把他们的实现，与框架形成中所占的位置 进行阐明，那么设计模式也将下神坛，提高软件人员实实在在的开发水平。

我做Eclipse插件大概5年左右时间，在此之前，对Adapter模式认识不够，一直觉得没有什么用处，但做了Eclipse后，才发现这个模式简直是太强大了，特别是结合Java这种半强半弱的语言，简直是绝配。搞得我最近写C++的时候，都把这个东东给加上了。

可以这样说，Eclipse没有了Adapter，就失去一大半平台的意义。

适配器的威力，与接口的威力一样强大！两者在框架地位中，有着等同的地位与作用。也就是说，适配器可以代替接口，仅仅接口更为简明罢了

ls在什么公司呀，我也想做eclipse插件，可惜没有这样的机会额。