研磨设计模式之策略模式-5

 

 

 

接策略模式-4，其实是讲的一个主题，写在一个里面超长了，只好分成了两个，请见谅！

 

 

 

3：扩展示例，实现方式一
        经过上面的测试可以看出，通过使用策略模式，已经实现好了两种支付方式了。如果现在要增加一种支付方式，要求能支付到银行卡，该怎么扩展最简单呢？
        应该新增加一种支付到银行卡的策略实现，然后通过继承来扩展支付上下文，在里面添加新的支付方式需要的新的数据，比如银行卡账户，然后在客户端使用新的上下文和新的策略实现就可以了，这样已有的实现都不需要改变，完全遵循开-闭原则。
        先看看扩展的支付上下文对象的实现，示例代码如下：

 

 

 

/**

 * 扩展的支付上下文对象

 */

public class PaymentContext2 extends PaymentContext {

    /**

     * 银行帐号

     */

    private String account = null;

    /**

     * 构造方法，传入被支付工资的人员，应支付的金额和具体的支付策略

     * @param userName 被支付工资的人员

     * @param money 应支付的金额

     * @param account 支付到的银行帐号

     * @param strategy 具体的支付策略

     */

    public PaymentContext2(String userName,double money,

String account,PaymentStrategy strategy){

       super(userName,money,strategy);

       this.account = account;

    }

    public String getAccount() {

       return account;

    }

}

 

然后看看新的策略算法的实现，示例代码如下： 

 

 

/**

 * 支付到银行卡

 */

public class Card implements PaymentStrategy{

    public void pay(PaymentContext ctx) {

       //这个新的算法自己知道要使用扩展的支付上下文，所以强制造型一下

       PaymentContext2 ctx2 = (PaymentContext2)ctx;

       System.out.println("现在给"+ctx2.getUserName()+"的"

+ctx2.getAccount()+"帐号支付了"+ctx2.getMoney()+"元");

       //连接银行，进行转帐，就不去管了

    }

}

 

最后看看客户端怎么使用这个新的策略呢？原有的代码不变，直接添加新的测试就可以了，示例代码如下： 

 

 

public class Client {

    public static void main(String[] args) {

       //创建相应的支付策略

       PaymentStrategy strategyRMB = new RMBCash();

       PaymentStrategy strategyDollar = new DollarCash();

      

       //准备小李的支付工资上下文

       PaymentContext ctx1 =

new PaymentContext("小李",5000,strategyRMB);

       //向小李支付工资

       ctx1.payNow();

      

       //切换一个人，给petter支付工资

       PaymentContext ctx2 =

new PaymentContext("Petter",8000,strategyDollar);

       ctx2.payNow();

      

       //测试新添加的支付方式

       PaymentStrategy strategyCard = new Card();

       PaymentContext ctx3 = new PaymentContext2(

"小王",9000,"010998877656",strategyCard);

       ctx3.payNow();

    }

}

 

再次测试，体会一下，运行结果如下： 

 

 

现在给小李人民币现金支付5000.0元

现在给Petter美元现金支付8000.0元

现在给小王的010998877656帐号支付了9000.0元

 

4：扩展示例，实现方式二
        同样还是实现上面这个功能：现在要增加一种支付方式，要求能支付到银行卡。
（1）上面这种实现方式，是通过扩展上下文对象来准备新的算法需要的数据。还有另外一种方式，那就是通过策略的构造方法来传入新算法需要的数据。这样实现的话，就不需要扩展上下文了，直接添加新的策略算法实现就好了。示例代码如下： 

 

 

/**

 * 支付到银行卡

 */

public class Card2 implements PaymentStrategy{

    /**

     * 帐号信息

     */

    private String account = "";

    /**

     * 构造方法，传入帐号信息

     * @param account 帐号信息

     */

    public Card2(String account){

       this.account = account;

    }

    public void pay(PaymentContext ctx) {

       System.out.println("现在给"+ctx.getUserName()+"的"

+this.account+"帐号支付了"+ctx.getMoney()+"元");

       //连接银行，进行转帐，就不去管了

    }

}

 

（2）直接在客户端测试就可以了，测试示例代码如下：  

 

public class Client {

    public static void main(String[] args) {

       //测试新添加的支付方式

       PaymentStrategy strategyCard2 = new Card2("010998877656");

       PaymentContext ctx4 =

new PaymentContext("小张",9000,strategyCard2);

       ctx4.payNow();

    }

}

 

 

运行看看，好好体会一下。

 （3）现在有这么两种扩展的实现方式，到底使用哪一种呢？或者是哪种实现更好呢？下面来比较一下：
        对于扩展上下文的方式：这样实现，所有策略的实现风格更统一，策略需要的数据都统一从上下文来获取，这样在使用方法上也很统一；另外，在上下文中添加新的数据，别的相应算法也可以用得上，可以视为公共的数据。但缺点也很明显，如果这些数据只有一个特定的算法来使用，那么这些数据有些浪费；另外每次添加新的算法都去扩展上下文，容易形成复杂的上下文对象层次，也未见得有必要。
        对于在策略算法的实现上添加自己需要的数据的方式：这样实现，比较好想，实现简单。但是缺点也很明显，跟其它策略实现的风格不一致，其它策略都是从上下文中来获取数据，而这个策略的实现一部分数据来自上下文，一部分数据来自自己，有些不统一；另外，这样一来，外部使用这些策略算法的时候也不一样了，不太好以一个统一的方式来动态切换策略算法。
        两种实现各有优劣，至于如何选择，那就具体问题，具体的分析了。

5：另一种策略模式调用顺序示意图
        策略模式调用还有一种情况，就是把Context当做参数来传递给Strategy，也就是本例示范的这种方式，这个时候策略模式的调用顺序如图4所示：


 

图4  策略模式调用顺序示意图二

 

 

 

未完待续......

评论

8 楼 superheizai 2010-08-20  

好博文！看到第二篇的时候，基本上就已经说明了策略模式的核心点上了。能从核心扩展到相关应用，扩展到与其它模式的相同与不同，也足以说明了楼主对模式的深刻理解！呵呵，继续期待其它模式。另外，建议初学模式的同学，可以看下其它简单的模式入门的书籍，再来阅读楼主的大作，相信那样我们可以学到更多！

7 楼 sarstime 2010-07-06  

坚决鼓励原创，而且lz写的也确实不错，不明白那些踩的什么意思。

6 楼 chjavach 2010-07-01  

to  vieri122 兄 ：原来内容是“被踩”的呀，我还在想得到大家的批评指点呢，可是只见踩，不见有朋友来不吝赐教，原来有误伤，哈哈！

to   weiyc_16000 兄：不好意思，由于本文的主题是设计模式，主要讨论的是策略模式本身，而不是具体的业务实现，因此，没有去提供更复杂处理的示例。但是在后面提到了，加入时间复杂性等，可以采用：“ 对于出现需要嵌套使用多个算法的情况，比如折上折、折后返卷等业务的实现，需要组合或者是嵌套使用多个算法的情况，可以考虑使用装饰模式、或是变形的职责链、或是AOP等方式来实现。”
   只是提到了方案，而没有深入去讲解和示例，见谅！

5 楼 weiyc_16000 2010-06-30  

期待后文。。。

正如第一个报价例子而言，再加入时间的复杂性（节假日具有更优惠的折扣）又会采用怎样的处理？

4 楼 cxqdji 2010-06-29  

无意闯进来,发现博主写得不错,先mark一下,再看看其他的文章,再做评价

3 楼 vieri122 2010-06-29  

写的很不错，期待楼主能坚持下来。
但是奇怪，我在顶篇blog时候，怎么自动又踩了一下。我用chrome浏览器，难道是javaeye系统的bug？

2 楼 lqingle 2010-06-28  

非常好，:idea: 期望楼主能多写些文章

1 楼 3shouxing 2010-06-28  

两种扩展方式对比分析和总结,很不错