设计模式整理_策略模式

  △策略模式用于在用户行为经常发生变化的情况下,将行为单独提取出来,定义算法族,采用组合的方式,分别封装起来,让他们可以互相替换,此模式,让算法的变化独立于使用算法的客户。

该模式体现了如下设计模式的原则:

  1. 封装变化。
  2. 多用组合,少用继承。
  3. 针对接口编程,而不针对实现编程。

  在策略模式中,第一点体现了对于类中变化的部分,进行了封装,第二部分体现了将算法族的接口定义在类中,采用组合的形式来完成对于类行为的定义,第三部分体现了利用借口代表每个行为,而将接口的具体实现交给其实现类来完成。下面是代码示例,采用了Duck类,其中将可能会发生变化的类单独分离成FlyBehavior接口和QuackBehavior接口,然后再实现类中定义接口的行为。在Duck类中,采用将两个接口组合的方式,定义行为,由于类存在不需要变化的行为参数,因此Duck类设置为abstract。在Demo演示的时候,先是演示ModelDuck,随后改变其FlyBehavior。

Duck类即子类:

 

public abstract class Duck {
    FlyBehavior flyBehavior;
    QuackBehavior quackBehavior;
    public Duck(){}
    public abstract void display();
    public void performFly() {
        flyBehavior.fly();
    }
    public void performQuack() {
        quackBehavior.quack();
    }
    public void setFlyBehavior(FlyBehavior flyBehavior) {
        this.flyBehavior = flyBehavior;
    }
    public void setQuackBehavior(QuackBehavior quackBehavior) {
        this.quackBehavior = quackBehavior;
    }
}
class ModelDuck extends Duck{
    public ModelDuck() {
        flyBehavior = new FlyNoWay();
        quackBehavior=new Quack();
    }
    @Override
    public void display() {
        // TODO Auto-generated method stub
        System.out.println("I am a Model Duck.");
    }

}

  FlyBehavior类即子类(可能变化的算法族)

 

public interface FlyBehavior {
    public void fly();
}
class FlyWithWings implements FlyBehavior {

    @Override
    public void fly() {
        System.out.println("I am flying!");
    }
}
class FlyNoWay implements FlyBehavior {

    @Override
    public void fly() {
        // TODO Auto-generated method stub
        System.out.println("I can‘t fly.");
    }

}
class FlyWithRocket implements FlyBehavior {

    @Override
    public void fly() {
        // TODO Auto-generated method stub
        System.out.println("I am flying with Rocket!");
    }

}

  QuackBehavior类即子类(可能变化的算法族)

public interface QuackBehavior {
    public void quack();
}
class Quack implements QuackBehavior {

    @Override
    public void quack() {
        // TODO Auto-generated method stub
        System.out.println("Quack");
    }

}
class MuteQuack implements QuackBehavior {

    @Override
    public void quack() {
        // TODO Auto-generated method stub
        System.out.println("Silence.");
    }

}

  演示类:

public class Demo {
    public static void main(String[] args) {
        Duck duck=new ModelDuck();
        duck.performFly();
        duck.performQuack();
        duck.display();
        duck.setFlyBehavior(new FlyWithRocket());
        duck.performFly();
    }
}

 UML图如下:

时间: 2024-10-25 04:53:52

设计模式整理_策略模式的相关文章

设计模式整理_组合模式

组合模式允许你将对象组成树形结构,来表现整体和部分的联系.组合能让客户以一致的方式处理个别对象和对象的组合. 组合模式将整体称为组合.(类似于树结构中的树),将组合下面没有其他元素相连的物件称为叶结点.其中,组合和叶结点有着共同的父类,可以将两者所有的方法抽象到父类中,并且对方法有默认的实现,这样如果叶结点或者组合不想实现某个方法的时候,就可以不实现方法.通过将菜单和项放在相同的结构中,我们创建了一个整体/部分的层次结构,即由菜单项和菜单组成的对象树.可以将它视为一个整体.任何一个菜单都可能是组

设计模式整理_状态模式

状态模式允许对象在内部状态改变的时候,改变它的行为,对象看起来好像修改了它的类.因为这个模式将状态封装成为独立的类,并将动作委托到代表当前状态的对象,而行为会随着内部状态而改变. 在状态模式中,Context内部持有状态,State接口定义了一个所有具体状态的共同接口,任何状态都实现这个相同的接口,这样一来,各个状态可以互相替换.具体状态实现状态接口,所以当Context改变状态的时候,行为也跟着改变.而不管在什么时候,只要有人调用Context的具体方法,它就会用来委托状态处理,下面用具体事例

设计模式整理_模板模式

模板模式在父类中定义了一个方法的模板,而子类可以动态的实现模板成分方法,但是模板中的方法顺序无法改变. 父类中的模板方法往往申明为final,用来保证方法不被子类覆盖,因为作为模板,是不可以改变的,但是模板方法内的一系列方法,可以由子类自己静态实现,同时在父类的模板方法中,可以定义钩子(hook)方法.方便子类对于模板方法的优化.下面用两个例子说明. /*没有钩子(hook)的模板方法,此时模板方法无法修改*/ public abstract class Model { public final

设计模式整理_工厂模式

一.简单工厂模式. 通常情况下,在代码中需要创建一系列对象的时候,如果需要创建新的同类型的对象,就需要对原代码进行修改,此时就不符合对修改关闭的原则,因此,我们将创建对象于使用对象的代码分隔开来,在工厂类中创建工厂,然后如果需要新的对象,只需要修改工厂的类即可. public interface Car /*在这里定义需要生成的实例,针对抽象组件*/{ public void run(); } class BenzCar /*实例*/ implements Car { @Override pub

设计模式整理_迭代器模式

迭代器模式提供了一种方法顺序访问一个聚合对象中的各个元素,而又不是暴露其内部的表示.将在聚合对象内部游走的任务放在迭代器上而不是放在聚合上,这样简化了聚合的接口和实现,也让责任各得其所. 例如在没有进行优化的下列代码中,在处理不同的对象的聚合的时候,获取了对象的内部实现,这对封装造成了破坏,另外一方面,当需要处理其他类型的聚合对象的时候,也会造成需要对源代码进行修改,不利于扩展. /* * 定义Food类,Food类是需要被聚合的对象 * */ public class Food { priva

设计模式整理_命令模式

命令模式将请求封装成对象,以便使用不同的请求,队列或者日志来参数化其他对象,命令模式也支持可撤销的操作.当需要将发出请求的对象和执行请求的对象解耦的时候,采用命令模式. 命令模式中有几个名词:调用者,命令,接受者,客户.客户负责创建命令和调用者,调用者将命令封装在自己里面,当客户需要执行某些操作的时候,调用者就将调用命令对象的方法,命令对象通知接受者执行操作.一个命令对象通过在特定的接受者上绑定一组动作来封装一个请求,调用者可以接受命令作为自己的参数,甚至在运行的时候动态的执行,命令可以支持撤销

设计模式整理_外观模式

外观模式提供了一个统一的接口,用来访问子系统中的一群接口,外观定义了一个高层的接口,让子系统更容易使用.因为有了外观,客户的工作将更加快捷简便. 组件建立后,将会组装于外观中,并直接将外观派发给客户,方便使用,因此外观模式简化了组件中的一系列接口,方便客户的操作.外观将客户从一个复杂的子系统中解耦.当需要简化并统一一个很大的接口或者一群复杂的接口时,使用外观. 下面是外观模式的具体使用,可以看出,通过外观模式,大大的简化了客户的操作,对于组件的操作将在具体的外观内部进行操作. //组件 publ

大话设计模式_策略模式(Java代码)

策略模式:定义算法家族,分别封装,让它们之间可以互相替换,此模式让算法的变化不会影响到使用算法的客户 简单描述:一个父类,多个子类实现具体方法.一个Context类持有父类的引用(使用子类实例化此引用),客户端代码只需要与此Context类交互即可 大话设计模式中的截图: 例子代码: 策略类: 1 package com.longsheng.strategy; 2 3 public abstract class Strategy { 4 5 public abstract double getR

设计模式进阶(一) 策略模式

摘自<Design Paterns_Elements of Reusable Object-Oriented Software> 上一系列偏重于入门,从本篇开启进阶系列,着重于设计模式的适用情景. 回顾入门系列 设计模式入门(一)  策略模式 1  Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary