zy19982004--设计模式学习一：策略模式

一.概念

     策略模式：它定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法的变化不会影响到使用算法的客户。

 

二.UML

 

1. Context(应用场景)，持有Strategry对象的引用。
2. Context能动态指定Strategry具体的实现。
3. Context要使用Strategry提供的算法。
4. Strategry(抽象策略类)，定义了算法的骨架。
5. ConcreteStrategryA-C实现类，提供算法的具体实现。

三.实例分析

     铁道部现需要一个订票网站，于是对外招标，有许多公司都参与了竞标，它们都有能力做出一个像样的网站出来。因为铁道部有钱撒，所以打算搞两三个系统出来，对外开放一个给大家订票，另外两个保留，一旦发现第一个系统不对劲，立马使用第二个系统。从这个里面，我们可以抽象出这样的几个类：

     ProjectPublisher：项目发布者，铁道部。

     ProjectTeamA-C：各个竞标公司。

     ProjectPublisher:

package com.zzy.strategry;

/**
 * 项目发布者-铁道部
 * @author eason
 */
public class ProjectPublisher {

    //持有ProjectTeam对象的引用
    private ProjectTeam projectTeam;

    public ProjectPublisher(ProjectTeam projectTeam) {
        this.projectTeam = projectTeam;
    }
    //使用ProjectTeam提供的算法
    public void publishProject() {
        projectTeam.finshProject();
    }
    //能动态指定ProjectTeam具体的实现
    public void setProjectTeam(ProjectTeam projectTeam) {
        this.projectTeam = projectTeam;
    }

}

 

     ProjectTeam

package com.zzy.strategry;
/**
 * 抽象策略类
 * @author eason
 */
public abstract class ProjectTeam {

    //定义了算法的骨架
    public abstract void finshProject();

}

 

     ProjectTeamA

package com.zzy.strategry;
/**
 * 策略实现类-每个竞标公司
 * @author eason
 */
public class ProjectTeamA extends ProjectTeam {

    //提供算法的具体实现
    public void finshProject() {
        //TODO
        System.out.println("ProjectTeamA完成这个网站");
    }

}

 

     TestStrategry

package com.zzy.strategry;
/**
 * 测试类-client
 * @author eason
 */
public class TestStrategry {

    public static void main(String[] args) {
        ProjectTeamA pa = new ProjectTeamA();
        ProjectTeamB pb = new ProjectTeamB();
        //首先ATeam的系统
        ProjectPublisher pub = new ProjectPublisher(pa);
        pub.publishProject();
        //媒体报道现在使用的订票网站，经常瘫痪
        //于是乎换了一个系统
        pub.setProjectTeam(pb);
        pub.publishProject();
    }

}

 

四.使用场景

1. 一件事情，有很多方案可以实现。
2. 我可以在任何时候，决定采用哪一种实现。
3. 未来可能增加更多的方案。
4. 策略模式让方案的变化不会影响到使用方案的客户。
5. 在铁道部的例子中，我强调的“网站瘫痪”是为了来说明上面的第2点。实际上，对购票者来说，使用哪个系统都能够到票，这个“够到票”就叫没有影响到使用方案的用户。

五.使用感受

1. 方便client使用，用户只需要拿到Context就能完成所有事情。
2. OO原则中的组合优于继承。
3. OO原则中的封装性。

     其他的优缺点，网上有，但我并不能完全理解，就不写了。