1700465497
public void doAnythinig（）{
1700465498
1700465499
this.strategy.doSomething（）；
1700465500
1700465501
}
1700465502
1700465503
}
1700465504
1700465505
高层模块的调用非常简单，知道要用哪个策略，产生出它的对象，然后放到封装角色中就完成任务了，如代码清单18-10所示。
1700465506
1700465507
代码清单18-10 高层模块
1700465508
1700465509
public class Client{
1700465510
1700465511
public static void main（String[]args）{
1700465512
1700465513
//声明一个具体的策略
1700465514
1700465515
Strategy strategy=new ConcreteStrategy1（）；
1700465516
1700465517
//声明上下文对象
1700465518
1700465519
Context context=new Context（strategy）；
1700465520
1700465521
//执行封装后的方法
1700465522
1700465523
context.doAnythinig（）；
1700465524
1700465525
}
1700465526
1700465527
}
1700465528
1700465529
策略模式就是这么简单，偷着乐吧，它就是采用了面向对象的继承和多态机制，其他没什么玄机。想想看，你真实的业务环境有这么简单吗？一个类实现多个接口很正常，你要有火眼金睛看清楚哪个接口是抽象策略接口，哪些是和策略模式没有任何关系，这就是你作为系统分析师的价值所在。
1700465530
1700465531
1700465532
1700465533
1700465535
设计模式之禅 18.3 策略模式的应用
1700465536
1700465537
18.3.1 策略模式的优点
1700465538
1700465539
❑算法可以自由切换
1700465540
1700465541
这是策略模式本身定义的，只要实现抽象策略，它就成为策略家族的一个成员，通过封装角色对其进行封装，保证对外提供“可自由切换”的策略。
1700465542
1700465543
❑避免使用多重条件判断
1700465544
1700465545
如果没有策略模式，我们想想看会是什么样子？一个策略家族有5个策略算法，一会要使用A策略，一会要使用B策略，怎么设计呢？使用多重的条件语句？多重条件语句不易维护，而且出错的概率大大增强。使用策略模式后，可以由其他模块决定采用何种策略，策略家族对外提供的访问接口就是封装类，简化了操作，同时避免了条件语句判断。
1700465546
[
上一页 ]
[ :1.700465497e+09 ]
[
下一页 ]