這是最近碰到的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作爲外蘊狀態傳遞給方法（或者也可以使用專門的狀態類作爲外蘊狀態）。
序列圖如下：
