代理模式和装饰模式的理解
代理模式
考虑现实生活中的代理商. 你想要进一批货,但是出于某种原因,你无法直接与生产商联系(有可能是因为你生产商与你相隔太远, 或者比如你进的货是军 火, 一般来说生产商也不会直接露面滴), 这时候你就需要一个代理商, 他能够接受你的订单, 并且也能给你需要的货品, 但是记住,代理商并不真正生产货品,他的能力在于他有办法从生产商那里给你搞到货品.
那么对于买家,也就是接口的调用者而言, 我并不关心你到底是代理商还生产商,我只要你能够跟我交易就可以. 从这角度理解的话,代理隔离了调用者和实现者直接的联系.
实际编码中的例子呢, 比如WebService的调用你就可以把他理解成一个(远程)代理.
装饰模式
语义上理解,装饰是什么呢? 装饰就是在原本的东西上添油加醋嘛. 装饰的原则就是,对于一个西瓜, 不管我怎么装饰,它始终都是一个西瓜, 我不能最终把它装饰一番之后当成土豆去卖.
举个例子,大家应该都买过那种现做的冰淇淋. 一般都是这样卖的, 普通的冰淇淋必选,上面可以加上各种葡萄干啊,榛子啊,蓝莓酱啊之类的,当然每加一样你就要多交一点钱啦:). 那针对这个给冰淇淋算价钱的问题, 写成代码呢, 差不多就是这样子的.
Java代码
//抽象冰淇淋
abstract class AbstractIceCream{
public abstract int getPrice();
}
//真正的冰淇淋
class IceCream extends AbstractIceCream{
public int getPrice(){
return 2; //原味冰淇淋只卖5块~~
}
}
//冰淇淋的巧克力装饰器
class ChocolateAdapter extends AbstractIceCream {
private AbstractIceCream iceCream; //to be adapted.
public ChocolateAdapter(AbstractIceCream iceCream){
this.iceCream = iceCream
}
public getPrice (){
return this.iceCream.getPrice()+3; //假设加一层巧克力要加3块钱好了~
}
}
//冰淇淋的蓝莓酱装饰器
class BlueberryAdapter extends AbstractIceCream {
private AbstractIceCream iceCream; //to be adapted.
public BlueberryAdapter(AbstractIceCream iceCream){
this.iceCream = iceCream
}
public getPrice (){
return this.iceCream.getPrice()+5; //假设加一层蓝莓酱要加5块钱好了~
}
}
//顾客来了
public class Client{
public static void main(String args[]){
//给我来个蓝莓冰淇淋
AbstractIceCream blueberryIceCream = new BlueberryAdapter(new IceCream());
//给我来个蓝莓巧克力冰淇淋~~
AbstractIceCream bb_ch_iceCream = new BlueberryAdapter(new ChocolateAdapter(new IceCream()));
//来了一个巧克力超级粉丝说,我要加3层巧克力~~
AbstractIceCream lot_of_chocolate_iceCream = new ChocolateAdapter(new ChocolateAdapter(new ChocolateAdapter(new IceCream())))
//然后算帐看看,你猜这些冰淇淋分别要多少钱呢...
println(blueberryIceCream.getPrice());
println(bb_ch_iceCream.getPrice());
println(lot_of_chocolate_iceCream.getPrice());
}
}
写成这样我想大家应该能理解了? 再啰嗦两句,装饰器模式实际上在一定程度上解决了一个问题, 那就是类继承的局限性,类爆炸. 像上面的例子中,用最原始的集成方案的话,大概需要一下几个类: 冰淇淋, 巧克力的冰淇淋, 草莓的冰淇淋, 巧克力和草莓都有的冰淇淋...貌似还可以接受,但由于这些辅料是可以随意组合的, 那么比如我又新添了一个辅料香草,那我就又要新增 N个子类..., 学过组合数学的同学就会知道, 其实没学的也知道, 这样一来子类的生长速度可是相当客观的. 而使用装饰器的话, 新增一个辅料,我只需新增一个装饰器类即可, 省心啊...看起来程序员的生活又美好了不是么?
ok, 我保证这是最后一句啰嗦:
所谓模式,其实就是最佳实践的总结. 所以要学透模式,一定要联系现实生活,先弄清楚什么情况下需要使用这个模式,否则凭空想象的话,很容易混淆不说,还抓不住精要.
考虑现实生活中的代理商. 你想要进一批货,但是出于某种原因,你无法直接与生产商联系(有可能是因为你生产商与你相隔太远, 或者比如你进的货是军 火, 一般来说生产商也不会直接露面滴), 这时候你就需要一个代理商, 他能够接受你的订单, 并且也能给你需要的货品, 但是记住,代理商并不真正生产货品,他的能力在于他有办法从生产商那里给你搞到货品.
那么对于买家,也就是接口的调用者而言, 我并不关心你到底是代理商还生产商,我只要你能够跟我交易就可以. 从这角度理解的话,代理隔离了调用者和实现者直接的联系.
实际编码中的例子呢, 比如WebService的调用你就可以把他理解成一个(远程)代理.
装饰模式
语义上理解,装饰是什么呢? 装饰就是在原本的东西上添油加醋嘛. 装饰的原则就是,对于一个西瓜, 不管我怎么装饰,它始终都是一个西瓜, 我不能最终把它装饰一番之后当成土豆去卖.
举个例子,大家应该都买过那种现做的冰淇淋. 一般都是这样卖的, 普通的冰淇淋必选,上面可以加上各种葡萄干啊,榛子啊,蓝莓酱啊之类的,当然每加一样你就要多交一点钱啦:). 那针对这个给冰淇淋算价钱的问题, 写成代码呢, 差不多就是这样子的.
Java代码
//抽象冰淇淋
abstract class AbstractIceCream{
public abstract int getPrice();
}
//真正的冰淇淋
class IceCream extends AbstractIceCream{
public int getPrice(){
return 2; //原味冰淇淋只卖5块~~
}
}
//冰淇淋的巧克力装饰器
class ChocolateAdapter extends AbstractIceCream {
private AbstractIceCream iceCream; //to be adapted.
public ChocolateAdapter(AbstractIceCream iceCream){
this.iceCream = iceCream
}
public getPrice (){
return this.iceCream.getPrice()+3; //假设加一层巧克力要加3块钱好了~
}
}
//冰淇淋的蓝莓酱装饰器
class BlueberryAdapter extends AbstractIceCream {
private AbstractIceCream iceCream; //to be adapted.
public BlueberryAdapter(AbstractIceCream iceCream){
this.iceCream = iceCream
}
public getPrice (){
return this.iceCream.getPrice()+5; //假设加一层蓝莓酱要加5块钱好了~
}
}
//顾客来了
public class Client{
public static void main(String args[]){
//给我来个蓝莓冰淇淋
AbstractIceCream blueberryIceCream = new BlueberryAdapter(new IceCream());
//给我来个蓝莓巧克力冰淇淋~~
AbstractIceCream bb_ch_iceCream = new BlueberryAdapter(new ChocolateAdapter(new IceCream()));
//来了一个巧克力超级粉丝说,我要加3层巧克力~~
AbstractIceCream lot_of_chocolate_iceCream = new ChocolateAdapter(new ChocolateAdapter(new ChocolateAdapter(new IceCream())))
//然后算帐看看,你猜这些冰淇淋分别要多少钱呢...
println(blueberryIceCream.getPrice());
println(bb_ch_iceCream.getPrice());
println(lot_of_chocolate_iceCream.getPrice());
}
}
写成这样我想大家应该能理解了? 再啰嗦两句,装饰器模式实际上在一定程度上解决了一个问题, 那就是类继承的局限性,类爆炸. 像上面的例子中,用最原始的集成方案的话,大概需要一下几个类: 冰淇淋, 巧克力的冰淇淋, 草莓的冰淇淋, 巧克力和草莓都有的冰淇淋...貌似还可以接受,但由于这些辅料是可以随意组合的, 那么比如我又新添了一个辅料香草,那我就又要新增 N个子类..., 学过组合数学的同学就会知道, 其实没学的也知道, 这样一来子类的生长速度可是相当客观的. 而使用装饰器的话, 新增一个辅料,我只需新增一个装饰器类即可, 省心啊...看起来程序员的生活又美好了不是么?
ok, 我保证这是最后一句啰嗦:
所谓模式,其实就是最佳实践的总结. 所以要学透模式,一定要联系现实生活,先弄清楚什么情况下需要使用这个模式,否则凭空想象的话,很容易混淆不说,还抓不住精要.
