|
锁定老帖子 主题：简单代理模式与策略模式的区别
精华帖 (0) :: 良好帖 (0) :: 新手帖 (8) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-05-25
francis.xjl 写道 XTU_xiaoxin 写道 这两者有可比性吗？如果能给我详细描述出代理模式与装饰模式的区别及各自使用场合，那才是对大家最大的帮助，了解非常透彻的兄弟说说呗
同求，我只能理解概念，不好意思~  代理模式 考虑现实生活中的代理商. 你想要进一批货,但是出于某种原因,你无法直接与生产商联系(有可能是因为你生产商与你相隔太远, 或者比如你进的货是军 火, 一般来说生产商也不会直接露面滴), 这时候你就需要一个代理商, 他能够接受你的订单, 并且也能给你需要的货品, 但是记住,代理商并不真正生产货品,他的能力在于他有办法从生产商那里给你搞到货品. 那么对于买家,也就是接口的调用者而言, 我并不关心你到底是代理商还生产商,我只要你能够跟我交易就可以. 从这角度理解的话,代理隔离了调用者和实现者直接的联系. 实际编码中的例子呢, 比如WebService的调用你就可以把他理解成一个(远程)代理. 装饰模式 语义上理解,装饰是什么呢? 装饰就是在原本的东西上添油加醋嘛. 装饰的原则就是,对于一个西瓜, 不管我怎么装饰,它始终都是一个西瓜, 我不能最终把它装饰一番之后当成土豆去卖. 举个例子,大家应该都买过那种现做的冰淇淋. 一般都是这样卖的, 普通的冰淇淋必选,上面可以加上各种葡萄干啊,榛子啊,蓝莓酱啊之类的,当然每加一样你就要多交一点钱啦:). 那针对这个给冰淇淋算价钱的问题, 写成代码呢, 差不多就是这样子的.
//抽象冰淇淋
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, 我保证这是最后一句啰嗦: 所谓模式,其实就是最佳实践的总结. 所以要学透模式,一定要联系现实生活,先弄清楚什么情况下需要使用这个模式,否则凭空想象的话,很容易混淆不说,还抓不住精要. |
| 返回顶楼 | |
|
发表时间：2010-05-25
tomorrow009 写道 francis.xjl 写道 XTU_xiaoxin 写道 这两者有可比性吗？如果能给我详细描述出代理模式与装饰模式的区别及各自使用场合，那才是对大家最大的帮助，了解非常透彻的兄弟说说呗
同求，我只能理解概念，不好意思~ 代理模式 考虑现实生活中的代理商. 你想要进一批货,但是出于某种原因,你无法直接与生产商联系(有可能是因为你生产商与你相隔太远, 或者比如你进的货是军 火, 一般来说生产商也不会直接露面滴), 这时候你就需要一个代理商, 他能够接受你的订单, 并且也能给你需要的货品, 但是记住,代理商并不真正生产货品,他的能力在于他有办法从生产商那里给你搞到货品. 那么对于买家,也就是接口的调用者而言, 我并不关心你到底是代理商还生产商,我只要你能够跟我交易就可以. 从这角度理解的话,代理隔离了调用者和实现者直接的联系. 实际编码中的例子呢, 比如WebService的调用你就可以把他理解成一个(远程)代理. 装饰模式 语义上理解,装饰是什么呢? 装饰就是在原本的东西上添油加醋嘛. 装饰的原则就是,对于一个西瓜, 不管我怎么装饰,它始终都是一个西瓜, 我不能最终把它装饰一番之后当成土豆去卖. 举个例子,大家应该都买过那种现做的冰淇淋. 一般都是这样卖的, 普通的冰淇淋必选,上面可以加上各种葡萄干啊,榛子啊,蓝莓酱啊之类的,当然每加一样你就要多交一点钱啦:). 那针对这个给冰淇淋算价钱的问题, 写成代码呢, 差不多就是这样子的.
//抽象冰淇淋
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, 我保证这是最后一句啰嗦: 所谓模式,其实就是最佳实践的总结. 所以要学透模式,一定要联系现实生活,先弄清楚什么情况下需要使用这个模式,否则凭空想象的话,很容易混淆不说,还抓不住精要.  不错，很受启发~
|
| 返回顶楼 | |
|
发表时间：2010-05-25
tomorrow009 写道 francis.xjl 写道 XTU_xiaoxin 写道 这两者有可比性吗？如果能给我详细描述出代理模式与装饰模式的区别及各自使用场合，那才是对大家最大的帮助，了解非常透彻的兄弟说说呗
同求，我只能理解概念，不好意思~ 代理模式 考虑现实生活中的代理商. 你想要进一批货,但是出于某种原因,你无法直接与生产商联系(有可能是因为你生产商与你相隔太远, 或者比如你进的货是军 火, 一般来说生产商也不会直接露面滴), 这时候你就需要一个代理商, 他能够接受你的订单, 并且也能给你需要的货品, 但是记住,代理商并不真正生产货品,他的能力在于他有办法从生产商那里给你搞到货品. 那么对于买家,也就是接口的调用者而言, 我并不关心你到底是代理商还生产商,我只要你能够跟我交易就可以. 从这角度理解的话,代理隔离了调用者和实现者直接的联系. 实际编码中的例子呢, 比如WebService的调用你就可以把他理解成一个(远程)代理. 装饰模式 语义上理解,装饰是什么呢? 装饰就是在原本的东西上添油加醋嘛. 装饰的原则就是,对于一个西瓜, 不管我怎么装饰,它始终都是一个西瓜, 我不能最终把它装饰一番之后当成土豆去卖. 举个例子,大家应该都买过那种现做的冰淇淋. 一般都是这样卖的, 普通的冰淇淋必选,上面可以加上各种葡萄干啊,榛子啊,蓝莓酱啊之类的,当然每加一样你就要多交一点钱啦:). 那针对这个给冰淇淋算价钱的问题, 写成代码呢, 差不多就是这样子的.
//抽象冰淇淋
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, 我保证这是最后一句啰嗦: 所谓模式,其实就是最佳实践的总结. 所以要学透模式,一定要联系现实生活,先弄清楚什么情况下需要使用这个模式,否则凭空想象的话,很容易混淆不说,还抓不住精要. 说得太好了。。。 |
| 返回顶楼 | |
