设计模式之策略模式-Srategy
##使用大话设计模式案例
1. uml
2. 代码
##Strategy策略类，定义所有支持的算法的公共接口
abstract class Strategy{
//算法方法
public abstract void AlgorithmInterface();
}##具体策略类
class ConcreteStrategyA extends Strategy{
@Override
public void AlgorithmInterface(){
//算法A实现方法
}
}
class ConcreteStrategyB extends Strategy{
@Override
public void AlgorithmInterface(){
//算法B实现方法
}
}
class ConcreteStrategyC extends Strategy{
@Override
public void AlgorithmInterface(){
//算法c实现方法
}
}##策略模式上下文
public class Context {
//持有一个具体策略的对象
private Strategy strategy;
/**
* 构造函数，传入一个具体策略对象
* @param strategy 具体策略对象
*/
public Context(Strategy strategy){
this.strategy = strategy;
}
/**
* 策略方法
*/
public void ContextInterface(){
strategy.AlgorithmInterface();
}
}##客户端代码
public static void main(String){
//选择使用的策略
Strategy s = new ConcreteStrategyA();
Context context = new Context(s);
context.ContextInterface();
}3. 策略模式特点
##优点
- 减少了各类算法与使用算法类之间的耦合
- 避免了使用多重判断
- 扩展性良好
##缺点
- 策略类会增多
- 所有策略类暴露在客户端（可以结合简单工厂类，在context上下文中处理）,将具体实现的职责由客户端转给了Context来承担，最大化减轻了客户端的职责。（但是由于还是使用了switch代码，增加一个类时，必须修改Context中的代码）
-
public class Context { //持有一个具体策略的对象 private Strategy strategy; /** * 构造函数，传入一个具体策略对象 * @param strategy 具体策略对象 */ public Context(Strategy type){ switch(type){ case "算法A": strategy = new ConcreteStrategyA(); break; ... } } /** * 策略方法 */ public void ContextInterface(){ strategy.AlgorithmInterface(); } }
4. 使用案例
引用https://www.cnblogs.com/zhangshitong/p/6007607.html的案例，相对容易理解。
容错恢复机制
容错恢复机制是应用程序开发中非常常见的功能。那么什么是容错恢复呢？简单点说就是：程序运行的时候，正常情况下应该按照某种方式来做，如果按照某种方式来做发生错误的话，系统并不会崩溃，也不会就此不能继续向下运行了，而是有容忍出错的能力，不但能容忍程序运行出现错误，还提供出现错误后的备用方案，也就是恢复机制，来代替正常执行的功能，使程序继续向下运行。
举个实际点的例子吧，比如在一个系统中，所有对系统的操作都要有日志记录，而且这个日志还需要有管理界面，这种情况下通常会把日志记录在数据库里面，方便后续的管理，但是在记录日志到数据库的时候，可能会发生错误，比如暂时连不上数据库了，那就先记录在文件里面，然后在合适的时候把文件中的记录再转录到数据库中。
对于这样的功能的设计，就可以采用策略模式，把日志记录到数据库和日志记录到文件当作两种记录日志的策略，然后在运行期间根据需要进行动态的切换。
在这个例子的实现中，要示范由上下文来选择具体的策略算法，前面的例子都是由客户端选择好具体的算法，然后设置到上下文中。
下面还是通过代码来示例一下。
（1）先定义日志策略接口，很简单，就是一个记录日志的方法，示例代码如下：
/**
* 日志记录策略的接口
*/
public interface LogStrategy {
/**
* 记录日志
* @param msg 需记录的日志信息
*/
public void log(String msg);
}
（2）实现日志策略接口，先实现默认的数据库实现，假设如果日志的长度超过长度就出错，制造错误的是一个最常见的运行期错误，示例代码如下：
/**
* 把日志记录到数据库
*/
public class DbLog implements LogStrategy{
public void log(String msg) {
//制造错误
if(msg!=null && msg.trim().length()>5){
int a = 5/0;
}
System.out.println("现在把 '"+msg+"' 记录到数据库中");
}
}
接下来实现记录日志到文件中去，示例代码如下：
/**
* 把日志记录到文件
*/
public class FileLog implements LogStrategy{
public void log(String msg) {
System.out.println("现在把 '"+msg+"' 记录到文件中");
}
}
（3）接下来定义使用这些策略的上下文，注意这次是在上下文里面实现具体策略算法的选择，所以不需要客户端来指定具体的策略算法了，示例代码如下：
（4）看看现在的客户端，没有了选择具体实现策略算法的工作，变得非常简单，故意多调用一次，可以看出不同的效果，示例代码如下：
（5）小结一下，通过上面的示例，会看到策略模式的一种简单应用，也顺便了解一下基本的容错恢复机制的设计和实现。在实际的应用中，需要设计容错恢复的系统一般要求都比较高，应用也会比较复杂，但是基本的思路是差不多的。
作者演示了策略的一种变体。
这个例子同时说明了设计中的另外一个重要的概念，单一职责原理。
单一职责原则(SRP)，就一个类而言应该仅有一个引起它变化的原因。
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计
当变化发生时，设计会遭受到意想不到的破坏。