java设计模式-策略模式

骑猪看日落 2021-09-28 18:14 335阅读 0赞

首先看下下面一段代码：

private static void vip(String vipLevel){
    		if("1".equals(vipLevel)){
    			System.out.println(vipLevel);
    		}else if("2".equals(vipLevel)){
    			System.out.println(vipLevel);
    		}else if("3".equals(vipLevel)){
    			System.out.println(vipLevel);
    		}else if("4".equals(vipLevel)){
    			System.out.println(vipLevel);
    		}else if("5".equals(vipLevel)){
    			System.out.println(vipLevel);
    		}else if("6".equals(vipLevel)){
    			System.out.println(vipLevel);
    		}else if("7".equals(vipLevel)){
    			System.out.println(vipLevel);
    		}
    	}
    
    	public static void main(String[] args) {
    		vip("3");
    	}

大量的使用if else，如果我们需要的判断有几十种情况，可想而知是不是相当恐怖，中间如果先要去掉或者新增某种情况的判断，就必须要去修改，功能虽说可以实现，但是这样的代码灵活性和扩展性太差，而且这也违反了设计原则之一的开闭原则（open-closed-principle）.  
**开闭原则：  
       对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。  
       对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。**  
有没有比较好的解决方式呢？当然了，我们可以使用策略模式解决。  
**定义：**  
        策略模式定义了一系列的算法，并将每一个算法封装起来，使每个算法可以相互替代，使算法本身和使用算法的客户端分割开来，相互独立  
**结构：**  
        1.策略接口角色IStrategy:用来约束一系列具体的策略算法，策略上下文角色ConcreteStrategy使用此策略接口来调用具体的策略所实现的算法。  
        2.具体策略实现角色ConcreteStrategy:具体的策略实现，即具体的算法实现。  
        3.策略上下文角色StrategyContext:策略上下文，负责和具体的策略实现交互，通常策略上下文对象会持有一个真正的策略实现对象，策略上下文还可以让具体的策略实现从其中获取相关数据，回调策略上下文对象的方法  
  
首先定义一个接口:

/**
     * 策略接口
     *
     */
    public interface IVipLevelStrategy {
    
    	public void vip();
    }

具体的策略实现：

/**
     * 一级vip
     *
     */
    public class VipLevel1 implements IVipLevelStrategy{
    
    	@Override
    	public void vip() {
    		System.out.println("我是一级VIP客户");
    		
    	}

/**
     * 二级vip
     *
     */
    public class VipLevel2 implements IVipLevelStrategy{
    
    	@Override
    	public void vip() {
    		System.out.println("我是二级VIP客户");
    		
    	}

等等多个实现。  
策略上下文：

public class VipLevelStrategyContext {
    
    	private IVipLevelStrategy vipLevelStrategy;
    
    	public VipLevelStrategyContext(IVipLevelStrategy vipLevelStrategy) {
    		super();
    		this.vipLevelStrategy = vipLevelStrategy;
    	}
    
    	public IVipLevelStrategy getVipLevelStrategy() {
    		return vipLevelStrategy;
    	}
    
    	public void setVipLevelStrategy(IVipLevelStrategy vipLevelStrategy) {
    		this.vipLevelStrategy = vipLevelStrategy;
    	}
    	
    	
    	/**
    	 * vip等级处理
    	 */
    	public void processVip(){
    		this.vipLevelStrategy.vip();
    	}
    	
    }

客户端调用

public class VipLevelClient {
    
    	public static void main(String[] args) {
    		//1.创建具体测策略实现
    		IVipLevelStrategy level1  = new VipLevel1 ();
    		//2.在创建策略上下文的同时，将具体的策略实现对象注入到策略上下文当中
    		VipLevelStrategyContext context = new VipLevelStrategyContext(level1);
    		 //3.调用上下文对象的方法来完成对具体策略实现的回调
    		context.processVip();
    		
    	}
    }

以上便是策略模式的完美实现。当然我们可以做相对应的改动，来解决我们开头所述的过多的if else代码，

先增加一个等级维护类，枚举类或者map都可以：

import java.util.HashMap;
    import java.util.Map;
    
    public class VipLevelMap {
    
    	public static final Map<String,IVipLevelStrategy> vipLevelDataMap = new HashMap<>();
    	static{
    		vipLevelDataMap.put("1", new VipLevel1());
    		vipLevelDataMap.put("2", new VipLevel2());
    		vipLevelDataMap.put("3", new VipLevel3());
    	}
    }

修改策略上下文代码，只需传入vip等级

public class VipLevelStrategyContext {
    
    	private VipLevelStrategyContext(){};
    	/**
    	 * vip等级处理
    	 */
    	public static void processVip(String vipLevel){
    		IVipLevelStrategy vipLevelStrategy = VipLevelMap.vipLevelDataMap.get(vipLevel);
    		vipLevelStrategy.vip();
    	}
    	
    }

修改客户端代码:

public class VipLevelClient {
    
    	public static void main(String[] args) {
    		String vipLevel = "1";
    		VipLevelStrategyContext.processVip(vipLevel);
    		vipLevel = "2";
    		VipLevelStrategyContext.processVip(vipLevel);
    	}
    }

输出结果:  
我是一级VIP客户  
我是二级VIP客户  
  
是不是很完美的解决了开头的if else代码呢？代码简洁了很多，可读性也提高了。，如果我们需要新增或者修改的时候，只需要维护VipLevelMap类和具体的策略实现就OK了。  
  
以上只是个人的简单理解理解和应用，有不对的地方请指出。策略模式的缺点是判断比较多的话，可能需要写很多的实现类。