设计模式之装饰模式

Posted lxjshuju

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了设计模式之装饰模式相关的知识,希望对你有一定的参考价值。

  1. 什么是装饰模式
    装饰( Decorator )模式又叫做包装模式。通过一种对client透明的方式来扩展对象的功能,是继承关系的一个替换方案。

  2. 装饰模式的结构
    技术分享

  3. 装饰模式的角色和职责

    抽象组件角色: 一个抽象接口,是被装饰类和装饰类的父接口。
    详细组件角色:为抽象组件的实现类。
    抽象装饰角色:包括一个组件的引用。并定义了与抽象组件一致的接口。
    详细装饰角色:为抽象装饰角色的实现类。负责详细的装饰。

以一个样例来解释一下,假设我们如今要想造一辆车,对 ! 就是车, Car。

大家都知道,不同的车功能不同,有的车能够跑,废话!

有的车能够飞,有的车能够游泳,有的车能够跳跃。

。。

别激动,我就举个样例。

依照传统的面向对象的思想,我们肯定先定义一个Car的父类,在这个父类中定义一些全部车都具有的功能,比方run(),然后再派生出各种子类继承这个Car父类,然后在子类中再实现自己独特的功能。比如。我声明一个FlyCar继承自Car,然后在FlyCar中实现父类的run()。在实现自己独特的fly()方法。

你是不是这么想的。别不承认。一般人都是酱紫想的。我也是这么想的,起初我还非常自豪。由于我用到了面向对象的思想!!!

可是,假设如今我想造一个既能游泳又能飞的车怎么办?难道我定义一个FlySwimCar继承自Car,OK,当然能够。

可是,随着科技的发展。车的功能越来越丰富,你难道要不停的定义各种组合功能的车吗。你应该知道排列组合吧~~~这显然不符合程序猿偷懒的个性。

所以。就有了 装饰模式。我们边看代码,边解释。

首先。定义一个Car基类,当然,这个必须是接口,你懂的。你不可能直接new 一个Car出来吧。谁知道这个Car是具有哪个功能的Car。可是这个接口Car中应该包括最主要的车的功能。

//Car.java
public interface Car {
    public void run();
    // 显示车的功能
    public void show();
}

最普通的车只是于实现这个接口了,这个车除了能跑之外,啥都不能干。

对,这就是传说中的 【跑车】。

//RunCar.java

public class RunCar implements Car{

    @Override
    public void run() {
        System.out.println("run...");
    }

    @Override
    public void show() {
        this.run();
    }

}

然后,我想造一辆能Fly的车。怎么办?

我们先定义一个抽象类CarDecorator。这个类干嘛的呢?就是对车进行包装。为啥是抽象的呢?由于你造一个能Fly的车和造一个能Swim的车,用的材料啥的肯定都不同吧,也就是说包装的内容都不同吧,所以,这个CarDecorator中定义的是包装类共同拥有操作。就好比。把一辆普通的车改造之前,不论你是改装成能Fly的车还是能Swim的车。你首先是不是获得这个普通的车,获得普通车这个操作就是在CarDecorator基类中定义的。

//CarDecorator.java
public abstract class CarDecorator {
    private Car car;

    public CarDecorator(Car car) {
        this.car = car;
    }
    //提供方法获取包装之前的Car
    //为什么要获取包装之前的Car。废话。不获得之前的Car。你怎么加入新的功能?
    //那么加入功能的方法在哪?我怎么没瞅见。别急呀,往下看,肯定是特定的装饰者加入特定的功能呀。

public Car getCar() { return car; } public void setCar(Car car) { this.car = car; } //为了显示车具有的功能。定以了这个show()方法 public abstract void show(); }

好了,如今我们就能够造能飞的车了。

//FlyCarDecorator.java

public class FlyCarDecorator extends CarDecorator {

    public FlyCarDecorator(Car car) {
        super(car);
    }

    @Override
    //显示车的功能
    public void show() {
        //先显示原始车的功能,这下知道为啥在CarDecorator中获得改造之前的车了吧。

this.getCar().show(); this.fly();//加入新的功能 } public void fly(){ System.out.println("fly..."); } }

同理,我们能够造一个能Swim的车子。

//SwimCarDecorator.java

public class SwimCarDecorator extends CarDecorator{

    public SwimCarDecorator(Car car) {
        super(car);
    }

    @Override
    public void show() {
        this.getCar().show();
        this.swim();
    }

    public void swim(){
        System.out.println("swim...");
    }
}

酱紫的话。主函数就会变得非常清爽。

//MainClass.java
public class MainClass {

    public static void main(String[] args) {

        Car car = new RunCar();
        car.show();

        System.out.println("--------------------");

        SwimCarDecorator swimCar = new SwimCarDecorator(car);
        swimCar.show();

        System.out.println("--------------------");
        FlyCarDecorator flyCar = new FlyCarDecorator(car);
        flyCar.show();

        System.out.println("--------------------");

    }
}

执行结果:

run...
--------------------
run...
swim...
--------------------
run...
fly...
--------------------

呵呵呵,是不是非常清爽。

可是你有木有发现一个问题,你说造一个能Fly能Swim的车,如今却仅仅造了一个能run和Siwm。能run和Fly的车,还要不要脸了。

各位看官,别激动。!

立即造。立即造。

正常人的思维是不是酱紫的,我有一个car,仅仅能run。跑车嘛!!

!如今改造(装饰)一下,能游泳了,然后我希望既能游泳也能飞。怎么办?废话,当然是把能游泳的车加一个翅膀啥的。

是不是?嗯,这次你想对了。我也是怎么想的。

如今我们改我们的main函数:

//MainClass.java

public class MainClass {

    public static void main(String[] args) {

        Car car = new RunCar();
        car.show();

        System.out.println("--------------------");
        //1
        Car swimCar = new SwimCarDecorator(car);
        swimCar.show();

        System.out.println("--------------------");
        //2                                3   
        Car flyCar = new FlyCarDecorator(swimCar);
        flyCar.show();

        System.out.println("--------------------");

    }
}

改了三处,和原来的main函数比較下,看见没有。

为什么这么改,你们不都是怎么想的吗???忘了?往上看看。

为了适应main函数这么改,我们改动其它的文件呢。我们看一下:

Car flyCar = new FlyCarDecorator(swimCar);

原来FlyCarDecorator的构造方法中传递的是Car。你如今传递的是swimCar。swimCar在没改之前是啥类型来着。对。是SwimCarDecorator类型。

辣么,你如今知道怎么改了吧。

我们让CarDecorator实现Car接口不就完了吗?
技术分享

然后分别在FlyDecorator中实现Car中没有实现的run方法
技术分享

技术分享

好了,代码应该不报错了吧。。。

如今看下执行结果:

技术分享
怎么样,我没食言吧。说给你造个能fly能swim的就给你造了。关键代码写得还是辣么的优雅!

!嘿嘿嘿,代码不是我写的,我仅仅是分析下。

可是,有人可能会问,你说改这就改这,说改那就改那,究竟改的合不合理呢?唉,你别说,这么一改。比之前还真的合理。

首先,是main方法中的调用逻辑,之前已经说过了,这肯定是符合大多人的思考习惯的。

然后,我们看下CarDecorator实现Car接口合不合理,我们看他的子类FlyDecorator,他继承自CarDecorator,CarDecorator实现了Car接口。所以,FlyDecorator要实现Car中的接口,Car中有两个方法一个是show()和run()。show()方法在CarDecorator中已经定义为抽象方法了,已经被FlyDecorator实现了,如今就剩下run()方法没有实现了。所以,FlyDecorator要实现run()方法。你想想,FlyDecorator实现run方法合理吗???我认为非常合理。你给车装个翅膀让他飞。他就不能跑了?也许人家跑的更快了呢。也许人家跑的姿势更优雅了呢?所以你也得给FlyDecorator改造车的同一时候改动原有功能的机会,是不是?所以我认为非常合理。

同理,SwimCarsDecorator中的也要实现Car接口中的run()方法。









以上是关于设计模式之装饰模式的主要内容,如果未能解决你的问题,请参考以下文章

Java设计模式之装饰者模式

设计模式之装饰者模式

设计模式 之 装饰者模式

设计模式之装饰器模式

设计模式之装饰者模式

学习设计模式之装饰器模式