adapter模式读书笔记,请多多指教
不能在使用它时增加额外的条件。当客户类使用它
时，当接口不匹配时，如果采用非面向对象的方法
，用硬代码调用这个类，势必会出现大量的重复代
码，出现重复代码的时候就是使用设计模式的时候。
这是可以用一个专门的类来封装这个匹配的过程。
这就是adapter,adapter有两种形式：类适配器
和对象适配器。用类适配器的好处是避免额外的
对象引用，并且可以重新定义被适配类的内容。
对象适配器的好处是可以为被适配类和它所有的
子类提供适配。
不能在使用它时增加额外的条件。当客户类使用它
时，当接口不匹配时，如果采用非面向对象的方法
，用硬代码调用这个类，势必会出现大量的重复代
码，出现重复代码的时候就是使用设计模式的时候。
这是可以用一个专门的类来封装这个匹配的过程。
这就是adapter,adapter有两种形式：类适配器
和对象适配器。用类适配器的好处是避免额外的
对象引用，并且可以重新定义被适配类的内容。
对象适配器的好处是可以为被适配类和它所有的
子类提供适配。
你说的“当客户类使用它时，接口不匹配，。。用硬代码调用这个类，势必产生大量重复代码”，我不是很明白，我的理解是，当接口不匹配时，一般我们要么修改原来的类或者修改现在的类，使它们接口来匹配，但是这种修改原来类的办法不是好办法，我们要把原来的类当做“黑匣子”，尽量不去动它，保证复杂系统的稳定性，这是就只能通过adapter增加一个类，来做转换，就象110/220的变压转换器一样。
这个模式告诉我们，不要随意去修改原来代码，不要自以为很聪明，我个人感觉这是很多年轻程序员最喜欢范的毛病。
关于 adapter 还有以下优点。
如果你需要做比如图象类型转换，要把 bmp, gif, png, jpg, tif, ... 等很多格式能够相互转化，一个一个写，你就需要很多个转换方法：
bmp->gif
bmp->png
bmp->jpg
bmp->tif
gif->bmp
gif->png
gif->jpg
gif->tif
png->bmp
png->gif
png->jpg
png->tif
... ...
而用 adapter 就方便多了，只需要
bmp->adapter
gif->adapter
png->adapter
jpg->adapter
tif->adapter
以及
adapter->bmp
adapter->gif
adapter->png
adapter->jpg
adapter->tif
工作量少的多了。
我可是记不住那些模式，我现在的做法就是
来了一个项目后，不管三七21整体上确定了
功能之后，就开始定义若干借口和抽象类
然后通过多态的方式使用对象，总能瞎猫碰死耗子
用了几个设计模式。
是不是扯远了
核心就是实现的每一个系统，甚至每一个功能
都要抽象出一个管理类（接口），从而实现
方便的系统扩充。
我认识一个搞高级语言研究的人，她是专门搞语言
扩充的，她研究的路子就是在一般的类上面再动态
的加入更高级的抽象类，这和模式的研究有异曲同工的
效果吧
虽然有些人不自觉地使用，但是比如说
同样的东西我要是给class命名加了
adapter这样的东西，和不加的相比，看起来
更专业一点。
没有办法应用
我对你说的图像各式转换比较感兴趣 我觉得你说的方法很好。你的意思是不是找一种中性格式，使得这种中性格式能够和其他的格式互相转换？不过我觉得这应该是Mediator模式。