一、 考察对象的Adapter模式
从上文看到，经过引入Adapter模式，原有的结构得到了改进。但我们还需要从客户的角度分析程序，使结构更加地合理。（这里，我们仅限于考察对 象的Adapter模式。类的Adapter模式不存在下述问题。这也印证了一个事实，就是：对象的Adapter模式和类的Adapter模式各有优 势，也各有缺点，设计时应根据实际情况考察。）
1、扩展的功能是否合理？
假设用户希望调用VedioMedia同时具有Play()和Resize()功能。从前面的描述来看，客户只需要实例化VedioAdapter类对象，就可以调用了。看来结构是正确的。
2、类型的扩展是否合理？
从目前的需求来看，要调用RM和MPEG类型的对象，没有任何问题。但是正如吕震宇所说，在VedioMedia类的Resize()方法中有一股 腐化的味道。坏味道的根源就是if 条件语句。如果要增加新的视频类型，就需要修改Resize()方法了。这是一个设计的权衡。其实这个味道虽然够坏，但好处是简单，也不用更多的对象；但 耦合性比较差。
如果我们的目标是希望更好的架构以支持耦合的松散，目前的结构就需要微调了。调整后的类图如下：
这样需要改变VedioAdapter类的代码：
public abstract class VedioAdapter:IVedioScreen
{
protected vedioMedia _vedio;
public VedioAdapter(vedioMedia vedio)
{
_vedio = vedio;
}
public void Play()
{
_vedio.Play();
}
public abstract void Resize();
}
然后实现RMAdapter和MPEGAdatper：
public class RMAdapter:VedioAdapter
{
public RMAdapter(VedioMedia vedio):base(vedio){}
public override void Resize()
{
MessageBox.Show("Change the RM screen's size.");
}
}
（MPEGAdapter的代码省略）
这样一改，要扩展就容易了，不过比之以前设计要复杂些，希望不会有人说我过度设计。如果要考虑正确性的话，RMAdapter的构造函数还需要考虑
异常情况。由于构造函数的参数为VedioMedia类型，因此，客户在调用时可能会传入MPEG类型，此时RMAdapter类型的Play()行为就
会发生改变。这也是和Decorator最大的不同，就是我们必须限制对象的Play()方法不能做任何改变。
public RMAdapter(VedioMedia vedio):base(vedio)
{
if (!(vedio is RM))
throw new Exception("VedioMedia object is not correct!");
}
3、 是否与原有客户系统兼容？
如果在原有的客户系统中提供了如下的类及方法：
public class MediaFile
{
public static void Play(IMedia media)
{
media.Play();
}
}
那么客户如下的调用是没有任何问题的：
MediaFile.Play(new RM());
然而，当客户要使用新的Adapter对象呢？例如：
MediaFile.Play(new RMAdapter());
显然是有
问题了，因为RMAdpater类没有实现IMedia接口，且RMAdpater类的Play()方法和IMedia接口的Play()方法在性质上也
是有区别的。此时，采用原有的设计就不正确了。改进的方法很简单，就是让VedioAdapter类实现IMedia接口就可以了：
public abstract class VedioAdapter:IVedioScreen,IMedia
{
……
}
根据吕震宇所说，当VedioAdapter类实现IMedia接口时，言外之意就是该Adapter也适合AudioMedia类型了。是否如此 呢？可以说是一半对，一半不对。对的原因，是由于AudioMedia类也实现了IMedia接口；但别忘了，我们适配的并非类，而是对象，也就是在 VedioAdapter中传递进来的VedioMedia对象。（如果我们将传递进来的对象扩展为IMedia，那就糟糕了。震宇兄的结论就完全成立 了。）同时，我们在构造函数的异常处理，也保证了AudioMedia类型对于VedioAdapter是非法的。
写到这里，我觉得本文已经超出了原来的设想，有些研究的味道了。嗯，还算不错。那么就继续研究下去吧。
二、 引入Decorator模式
按照最初的需求，我引入Decorator模式试一试。最初的需求是，需要为RM和MPEG类在不改变原有代码的情况下，添加Resize()方法，而其原来的Play()方法不变。调整设计类图：
上图的橙红色区域为Decorator模式的主体，至于IVedioScreen接口，仅仅是为VedioDecorator增加Resize()方法而引入的，其本身与Decorator无关，除非我要实现的Decorator功能，通过该接口来实现。代码如下：
public abstract class VedioDecorator:VedioMedia,IVedioScreen
{
private VedioMedia _vedio;
public VedioAdapter(vedioMedia vedio)
{
_vedio = vedio;
}
public VedioMedia Vedio
{
get {return _vedio;}
}
public abstract void Resize();
}
注意看，与前面Adapter模式的VedioAdapter类比较，除增加了对VedioMedia的派生外，还减少了Play()，因为该方法
已经从VedioMedia类中派生获得。这样的话，RMDecorator和MPEGDecorator，也需要做相应的改变：
public class RMDecorator:VedioDecorator
{
public RMDecorator (VedioMedia vedio):base(vedio)
{
if (!(vedio is RM))
throw new Exception("VedioMedia object is not correct!");
}
public override void Play()
{
Vedio.Play();
}
public override void Resize()
{
MessageBox.Show("Change the RM screen's size.");
}
}
到这个时候，我忽然觉得引入Decorator模式，已经有些力不从心了。为什么呢？最大的障碍就是我们的需求不能更改VedioMedia类型 Play()方法的既有行为。这个时候，所谓的Decorator已经失去了原来的意义。其实我觉得，此时的设计，应该是结合了Adapter模式与 Decorator模式而衍生出的新的结构。
那么，我为什么还要在本文提出引入Decorator模式呢。这来源我对于设计模式一向的观点：不要为了模式而模式！GOF的23种模式，并非茴香 豆的“茴”字，我也并非孔乙己，要你回答“茴”字的写法，却忽略了使用设计模式的真正精神。设计模式归根结底是拿来用的。只要符合你的要求，各种模式随你 怎么变都可以。因此，不管是前文所述的Adapter模式，还是改进后的Adapter模式，或者引入的Decorator模式，其中的变化是灵活的，选 择权最终还是你。
三、 正宗的Decorator模式
不过，我还是很有兴趣继续探讨下去，仍然借助媒体播放这个例子，来谈一谈Decorator模式的一般应用。现在我们要求RM和MPEG媒体在播放 前，首先要显示媒体文件的版权信息。请注意，这个需求，并非是为RM等媒体增加ShowCopyright()方法，而Play()方法保持不变。恰恰相 反，新的需求装饰了Play()的行为，它要求Play()的同时能够支持ShowCopyright的功能。类图如下：
在这里，VedioDecorator是装饰类的抽象类，而CopyRightVedioDecorator类则具体装饰了Play()的功能。
public abstract class VedioDecorator:VedioMedia
{
private VedioMedia _vedio;
public VedioAdapter(vedioMedia vedio)
{
_vedio = vedio;
}
public VedioMedia Vedio
{
get {return _vedio;}
}
}
然后实现CopyRightVedioDecorator类，为Play()方法装饰显示版权信息的功能：
public class CopyRightVedioDecorator:VedioDecorator
{
private CopyRight _copyRightMark;
public CopyRight CopyRightMark
{
get {return _copyRightMark;}
set {_copyRightMark = value;}
}
public override void Play()
{
_copyRightMark.ShowCopyRight();
Vedio.Play();
}
}
我们还可以继续装饰VedioMedia的Play行为，例如，要求在播放媒体文件之前，必须放一段广告，那么我们可以继续提供一个AdvertisementVedioDecorator装饰类。道理与上一样，不再赘述。
通过本例，我们可以看到Decorator模式与对象的Adapter模式的区别。
实现的区别：
1、 Decorator抽象类应继承要装饰的类，同时又聚合该类的实例对象；而对象的Adapter模式则只聚合，不继承；
2、 Decor模式并没有引入新的接口，除非要装饰的行为需要使用该接口；而对象的Adapter模式则引入了新的接口，以此来装配原有的对象，使其具有了新接口的方法；
因此，适用的场景也就有所不同：
1、 Decorator模式如其名，一般并不提供新的行为，而是在原有的行为上进行补充，即装饰的含义。
2、 Adapter模式则是为对象引入新的行为，使其匹配新的接口，即为适配的意义所在。
Hello! I Am David.DU.