设计模式—行为型—策略模式

最新推荐文章于 2021-07-02 15:34:17 发布

秦歌666

最新推荐文章于 2021-07-02 15:34:17 发布

阅读量377

点赞数

分类专栏：设计模式

本文链接：https://blog.csdn.net/sunqingzhong44/article/details/51819029

版权

设计模式专栏收录该内容

27 篇文章 0 订阅

订阅专栏

设计模式行为型

策略模式

策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。
它定义了算法家族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化，不会影响到使用算法的客户
角色：
抽象策略角色Strategy：策略类，通常由一个接口或者抽象类实现。
具体策略角色ConcreteStrategy：包装了相关的算法和行为。
环境角色Context：持有一个策略类的引用，最终给客户端调用。
应用场景：
1、多个类只区别在表现行为不同，可以使用Strategy模式，在运行时动态选择具体要执行的行为。
2、需要在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现。
3、对客户隐藏具体策略(算法)的实现细节，彼此完全独立。

优点：
1、策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码转移到父类里面，从而避免重复的代码。
2、策略模式提供了可以替换继承关系的办法。继承可以处理多种算法或行为。如果不是用策略模式，那么使用算法或行为的环境类就可能会有一些子类，每一个子类提供一个不同的算法或行为。但是，这样一来算法或行为的使用者就和算法或行为本身混在一起。决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻辑混合在一起，从而不可能再独立演化。继承使得动态改变算法或行为变得不可能。
3、使用策略模式可以避免使用多重条件转移语句。多重转移语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重转移语句里面，比使用继承的办法还要原始和落后。
缺点：
1、客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。

2、策略模式造成很多的策略类，每个具体策略类都会产生一个新类。有时候可以通过把依赖于环境的状态保存到客户端里面，而将策略类设计成可共享的，这样策略类实例可以被不同客户端使用。换言之，可以使用享元模式来减少对象的数量。

类图

代码实现

商场优惠活动，一种是全场9折，一种是满500减100

public interface Strage {
    Double discount(Double price);
}

//折扣
public class DiscountStrage implements Strage {

    private int discount;

    public DiscountStrage(int discount) {
        this.discount = discount;
    }

    @Override
    public Double discount(Double price) {
        return price/0*discount;
    }
}
//满减
public class RebateStrage implements Strage {

    private Double totalAmount;

    private Double returnAmount;

    public Double getTotalAmount() {
        return totalAmount;
    }

    public void setTotalAmount(Double totalAmount) {
        this.totalAmount = totalAmount;
    }

    public RebateStrage(Double totalAmount, Double returnAmount) {
        this.totalAmount = totalAmount;
        this.returnAmount = returnAmount;
    }

    @Override
    public Double discount(Double price) {
        if(price>totalAmount) {
            return price-returnAmount;
        }
        return price;
    }
}


public class Context {

    private static final Map<String,Strage> strages = new HashMap<String,Strage>();

    static {
        strages.put("discount",new DiscountStrage(9));
        strages.put("rebate",new RebateStrage(500d,100d));
    }

    public static  Strage getStrage(String type) {
        if (type == null || type.isEmpty()) {
            throw new IllegalArgumentException("type should not be empty.");
        }
        return strages.get(type);
    }
}

一般来讲，如果策略类是无状态的，不包含成员变量，只是纯粹的算法实现，这样的策略对象是可以被共享使用的，不需要在每次调用 getStrategy() 的时候，都创建一个新的策略对象。针对这种情况，我们可以使用上面这种工厂类的实现方式，事先创建好每个策略对象，缓存到工厂类中，用的时候直接返回。相反，如果策略类是有状态的，根据业务场景的需要，我们希望每次从工厂方法中，获得的都是新创建的策略对象，而不是缓存好可共享的策略对象，那我们就需要按照如下方式来实现策略工厂类。

  public static  Strage getStrage(String type) {
        if (type == null || type.isEmpty()) { 
            throw new IllegalArgumentException("type should not be empty."); 
        } 
        if (type.equals("discount")) { 
            return new DiscountStrage(); 
        } else if (type.equals("rebate")) { 
            return new RebateStrage(); 
        }
        return null;
    }