两道设计模式的面试题
两道设计模式的面试题
这是最近碰到的2个设计模式的面试题，大概如此：
1, Windows Media Player和RealPlayer是常用的媒体播放器，它们的API结构和调用方法非常不同，现在你的应用需要同时支持调用这2种播放器的API。你要怎么设计？
2, 现在有一种空调，它支持3种模式：Hot Air，Cool Air 和DoNothing。例如，当选择Hot Air模式时，再选择温度为20度，空调将输送热风；选择 Cool Air模式，温度设置为20度时，将输送冷风；在选择DoNothing模式时，空调什么都不做。 你将考虑如何为空调设计应用程序？如果将来空调需要增加支持新的模式呢？
下面是我的解答，权当抛砖引玉。
一、 第一题的解：适配器模式+抽象工厂模式
我采用了抽象工厂模式+适配器模式，先上图：
设计的重点是：
1,首先看适配器模式。MediaPlayerClassA和RealPlayerClassA都实现了IMediaA接口。MediaPlayerClassA调用MediaPlayer的APIs来实现IMediaA接口定义的功能；RealPlayerClassA则调用RealPlayer APIs。
2,再来看抽象工厂模式。MediaPlayerFactory和RealPlayerFactory继承自抽象类MediaFactory类，MediaPlayerFactory用来创建MediaPlayer产品族；RealPlayerFactory用来创建RealPlayer产品族。虽然上图中只画出了IMediaA接口，但事实上我们可能需要实现多个接口如IMediaB，IMediaC等，这就是这里为什么使用抽象工厂模式。
3,抽象类MediaFactory实现了一个静态方法CreateFactory，用来创建具体工厂，该方法返回MediaFactory类型的对象给Client，这样，Client不就需要知道它操作的是那个具体工厂。CreateFactory方法采用反射技术，这样，不需要修改CreateFactory方法的代码，就可以支持以后添加新的具体工厂。
4,工厂类返回IMediaA接口给Client，Client操作IMediaA接口而不需要知道它具体使用的是MediaPlayerClassA还是RealPlayerClassA的实例。
序列图如下：
二、 第二题的解：Flyweight模式
我采用了Flyweight模式，先上图:
设计的重点是：
1,把AirConditioner和它支持的Model分离开来，在AirConditioner类的实例中保存它支持的所有Model类的实例，这样做的好处是1)如果只是支持的Model有变化，不需要去实现新的AirConditioner类，只要添加或删除支持的Model即可。2)多个不同的AirConditioner类可以方便地共享共同的Model类，否则，可能需要复杂的继承关系才能在不同AirConditioner类之间共享Model。事实上，AirConditioner类和Model类的关系非常类似于桥梁模式中抽象类和实现类的关系。
2,采用Flyweight模式。在多个AirCondition实例中，共享Model的实例，这样可以大大地节省存储空间。ModelFactory用于创建Model实例并返回给AirCondition，它保存了一个Model池，每种类型的Model只有一个实例。在Model类中只保存内蕴状态，AirConditioner类保存外蕴状态，调用Model类的Execute方法时，需要把IAirConditioner作为外蕴状态传递给方法（或者也可以使用专门的状态类作为外蕴状态）。
序列图如下：
