结构型设计模式01-装饰模式

最新推荐文章于 2024-07-27 18:05:15 发布
最新推荐文章于 2024-07-27 18:05:15 发布
阅读量253 收藏
点赞数
分类专栏： 设计模式 文章标签： 设计模式 java 开发语言
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_56098191/article/details/130886795
版权

✨作者：猫十二懿

❤️‍🔥账号：CSDN 、掘金 、个人博客 、Github

🎉公众号：猫十二懿

装饰模式

1、 问题引入

要实现一个简单的个人形象系统，使用控制台输出的形式，简单说明搭配着装

Person

package com.shier.decorate;

/**
 * @author Shier
 * CreateTime 2023/4/16 22:30
 */
public class Person {
    private String name;

    public Person(String name) {
        this.name = name;
    }

    public void wearTShirts() {
        System.out.print("大T恤");
    }

    public void wearBigTrouser() {
        System.out.print("垮裤");
    }

    public void wearSneakers() {
        System.out.print("球鞋");
    }

    public void wearSuit() {
        System.out.print("西装");
    }

    public void wearTie() {
        System.out.print("领带");
    }

    public void wearLeatherShoes() {
        System.out.print("皮鞋");
    }

    public void wearBdk() {
        System.out.print("背带裤");
    }

    public void show() {
        System.out.println(name + "的装扮");
    }

}

测试类：

/**
 * @author Shier
 * CreateTime 2023/4/16 22:35
 */
public class DecorateTest {
    public static void main(String[] args) {
        Person person = new Person("Ikun");
        person.show();
        System.out.print("第一套装扮：");
        person.wearBigTrouser();
        person.wearBdk();

        System.out.println();
        System.out.print("第二套装扮：");
        person.wearTie();
        person.wearSuit();
        person.wearLeatherShoes();
    }
}

输出结果：

image-20230416224149866

问题来了：新的需求出现就要修改原来的Person类，这样就违背了开闭原则

2、 改进程序

修改后的程序结构图如下：

image-20230416224454204

将服饰抽象成一个类，让那么其他服饰类去继承这个服饰抽象类

Person类：

/**
 * @author Shier
 * CreateTime 2023/4/16 22:30
 */
public class Person {
    private String name;

    public Person(String name) {
        this.name = name;
    }
    public void show() {
        System.out.println(name + "的装扮");
    }
}

服饰抽象类：

/**
 * @author Shier
 * CreateTime 2023/4/16 22:46
 */
public abstract class Finery {
    public abstract void show();
}

Bdk 类

/**
 * @author Shier
 * CreateTime 2023/4/16 22:47
 */
public class Bdk extends Finery{
    @Override
    public void show() {
        System.out.print("背带裤");
    }
}

其他的服饰类一样，在此不多写了，都是重复的

客户端如下：

public class DecorateTest {
    public static void main(String[] args) {
        Person person = new Person("Ikun");
        person.show();
        System.out.print("第一套装扮：");
        Finery tShirts = new TShirts();
        Finery bigTrouser = new BigTrouser();
        Finery sneakers = new Sneakers();
        tShirts.show();
        bigTrouser.show();
        sneakers.show();
        System.out.println();
        System.out.print("第二套装扮：");
        Suit suit = new Suit();
        Bdk bdk = new Bdk();
        suit.show();
        bdk.show();
    }
}

输出的结构如下：

image-20230416225249019

如上的程序还是有问题的，什么问题呢？你看在客户端处都在调用很多的show方法，重复代码过多，最重要的是这些show执行的顺序。

那么我们就需要把所需的功能按正确的顺序串联起来进行控制 ，下面就用装饰模式去修改它

3、装饰模式

装饰模式（Decorator Pattern）是一种结构型设计模式。它允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式是作为现有的类的一个包装，创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。装饰器模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。装饰器模式针对的问题是动态地给一个对象添加一些额外的职责，就增加功能来说，装饰器模式相比生成子类更为灵活。装饰模式不改变接口的前提下，增强所考虑的类的性能。总之，装饰模式可以让我们动态地给一个对象添加一些额外的职责，而不需要在继承体系中创造许多子类。可以看做是一种对继承的补充或者替代方案。

3.1 装饰模式的结构图

image-20230416230107814

  • Component：定义一个对象接口，可以给这些对象动态地添加职责
  • ConcreteComponent：定义了一个具体的对象，也可以给这个对象添加一些职责
  • Decorator：装饰抽象类，继承了Component，从外类来扩展Component类的功能，但对于Component来说，是无须知道Decorator的存在的
  • ConcreteDecorator：具体的装饰对象，起到给Component添加职责的功能

如果只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator类可以是ConcreteComponent的一个子类。同样道理，如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。

3.2 原理

装饰模式是利用SetComponent来对对象进行包装，每个装饰对象的实现就和如何使用这个对象分离开了，每个装饰对象只关心自己的功能，不需要关心如何被添加到对象链当中。

在装饰模式中引入了装饰类，装饰类和被装饰类都要实现同一个接口或者继承同一个父类。具体来说，装饰类继承自抽象构件类，并且包含一个指向具体构件对象的引用，它包含了一个与抽象构件类相同的接口，即在装饰模式中，所有的装饰器都需要实现被装饰者实现的接口。因此客户端可以针对抽象构件角色进行编程，而不需要关心具体构件的类型。

装饰模式通过组合的方式，将装饰类和被装饰类进行组合，从而实现动态地添加新的功能。在运行时，装饰类动态地为被装饰类添加新的行为或者修改原有的行为，这样就可以在不修改现有代码的情况下，对需要修改的代码进行扩展和修改。这种方式比继承更加灵活和可控，避免了类爆炸问题，同时也实现了代码的复用。

3.3 使用装饰模式改进以上程序

再次修改的代码结构UML图如下：

image-20230416230740254

ICharactor接口（Component）

/**
 * @author Shier
 * CreateTime 2023/4/16 23:08
 * 人物形象接口
 */
public interface ICharacter {
    public void show();
}

Person类（ConcreteComponent）

/**
 * @author Shier
 * CreateTime 2023/4/16 22:30
 */
public class Person implements ICharacter{
    private String name;

    public Person(String name) {
        this.name = name;
    }
    public void show() {
        System.out.println(name + "的装扮");
    }
}

Finery类(Decorator)：

/**
 * @author Shier
 * CreateTime 2023/4/16 22:46
 */
public  class Finery implements ICharacter {
    private ICharacter character;

    public void decorate(ICharacter iCharacter) {
        this.character = iCharacter;
    }

    public  void show(){
        if (this.character !=null){
            this.character.show();
        }
    }
}

具体服饰类(ConcreteDecorator)：

/**
 * @author Shier
 * CreateTime 2023/4/16 22:47
 */
public class Bdk extends Finery {
    @Override
    public void show() {
        System.out.print("背带裤");
        super.show();
    }
}

每一个服饰类都一样的，不再过多写出来

测试类如下：

/**
 * @author Shier
 * CreateTime 2023/4/16 22:35
 */
public class DecorateTest {
    public static void main(String[] args) {
        Person kun = new Person("Ikun");
        System.out.print("第一套装扮：");
        // 穿球鞋的Ikun
        Sneakers sneakers = new Sneakers();
        sneakers.decorate(kun);
        // 在穿球鞋的Ikun基础上，再给他穿一条背带裤
        Bdk bdk = new Bdk();
        bdk.decorate(sneakers);
        bdk.show();
        System.out.println();
        System.out.print("第二套装扮：");
        // 穿西装的ikun
        Suit suit = new Suit();
        suit.decorate(kun);
        // 在穿西装的ikun基础上再传一个皮鞋
        LeatherShoes leatherShoes = new LeatherShoes();
        leatherShoes.decorate(suit);
        // 在穿西装和皮鞋的基础上带零领带
        Tie tie = new Tie();
        tie.decorate(leatherShoes);
        tie.show();

    }
}

测试结构如下：

image-20230416232052010

到此就实现了装饰模式去打扮ikun

如果还有新的需求过来，比如说ikun现在向买一个草帽带一下，只要增加一个草帽类，再去测试类当中给ikun穿上。ikun很满意

草帽类如下：

/**
 * @author Shier
 * CreateTime 2023/4/16 23:23
 */
public class Strawhat extends Finery {
    public void show() {
        System.out.print("草帽");
        super.show();
    }
}

测试类：

image-20230416232553668

测试结果如下：

image-20230416232513146

4、商场收银程序升级

装饰模式有一个重要的优点，把类中的装饰功能从类中搬移去除，这样可以简化原有的类。

所有商场系统的UML如改成如下：

image-20230416233049004

ISale接口（Component）

/**
 * @author Shier
 * CreateTime 2023/4/16 23:32
 */
public interface ISale {
    public double acceptCash(double price, int num);
}

CashSuper原来是抽象类，改成普通类，但实现ISale接口。

/**
 * @author Shier
 * CreateTime 2023/4/10 21:51
 */
public class CashSuper implements ISale {
    private ISale sale;

    // 装饰对象
    public void decorate(ISale iSale) {
        this.sale = iSale;
    }

    public double acceptCash(double price, int num) {
        double result = 0d;
        if (this.sale != null) {
            // 若装饰对象存在，则执行装饰对象的算法
            result = this.sale.acceptCash(price, num);
        }
        return result;
    }
}

CashNormal，相当于ConcreteComponent，是最基本的功能实现，也就是单价×数量的原价算法。

/**
 * @author Shier
 * CreateTime 2023/4/10 21:54
 *
 * 正常收费，原价返回
 */
public class CashNormal implements ISale {
    // 原价
    public double acceptCash(double price,int num){
        return price * num;
    }
}

另外两个CashSuper的子类算法，都在计算后，再增加一个super.acceptCash(result, 1)返回。

public class CashRebate extends CashSuper {
    private double moneyRebate = 1d;

    //初始化时必需输入折扣率。八折就输入0.8
    public CashRebate(double moneyRebate) {
        this.moneyRebate = moneyRebate;
    }

    //计算收费时需要在原价基础上乘以折扣率
    public double acceptCash(double price, int num) {
        double result = price * num * this.moneyRebate;
        return super.acceptCash(result, 1);
    }
}

image-20230416234052249

重点在CashContext类，因为涉及组合算法，所以用装饰模式的方式进行包装，这里需要注意包装的顺序，先打折后满多少返多少，与先满多少返多少，再打折会得到完全不同的结果。

/**
 * @author Shier
 * CreateTime 2023/4/11 22:55
 */
public class CashContext {
    /**
     * CashSuper对象
     */
    private ISale cashSuper;

    /**
     * 通过构造方法，传入具体的收费策略
     */
    public CashContext(int cashType) {
        //根据用户输入，将对应的策略对象作为参数传入CashContent对象中
        switch (cashType) {
            case 1:
                cashSuper = new CashNormal();
                break;
            case 2:
                cashSuper = new CashRebate(0.8d);
                break;
            case 3:
                cashSuper = new CashRebate(0.7d);
                break;
            case 4:
                cashSuper = new CashReturn(300d, 100d);
                break;
            case 5:
                // 先打8折，再满300反100
                CashNormal cn = new CashNormal();
                CashReturn cr = new CashReturn(300d, 100d);
                CashRebate cr2 = new CashRebate(0.8d);
                cr.decorate(cn);
                cr2.decorate(cr);
                this.cashSuper = cr2;
                break;
            case 6:
                // 先满200反50，再打七折
                CashNormal cn2 = new CashNormal();
                CashRebate cr3 = new CashRebate(0.7d);
                CashReturn cr4 = new CashReturn(200d, 40d);
                cr3.decorate(cn2);
                cr4.decorate(cr3);
                this.cashSuper = cr4;
                break;
            default:
                break;
        }
    }

    /**
     * 根据不同的收费策略返回不同的结构
     */
    public double getResult(double price, int num) {
        return cashSuper.acceptCash(price, num);
    }
}

客户端不用改变

最终测试结果如下：

image-20230416235135253

5、装饰模式总结

优点

  1. 装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
  2. 可以通过一种动态的方式来扩展一个对象的功能，通过配置文件可以在运行时选择不同的装饰器，从而实现不同的行为。
  3. 通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合。可以使用多个具体装饰类来装饰同一对象，得到功能更为强大的对象。
  4. 具体构件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体构件类和具体装饰类，在使用时再对其进行组合，原有代码无须改变，符合“开闭原则”。

缺点：

  1. 使用装饰模式进行系统设计时将产生很多小对象，这些对象的区别在于它们之间相互连接的方式有所不同，而不是它们的类或者属性值有所不同，同时还将产生很多具体装饰类。这些装饰类和小对象的产生将增加系统的复杂度，加大学习与理解的难度。
  2. 这种比继承更加灵活机动的特性，也同时意味着装饰模式比继承更加易于出错，排错也很困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为烦琐。

适用环境：

  1. 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
  2. 需要动态地给一个对象增加功能，这些功能也可以动态地被撤销。
  3. 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。不能采用继承的情况主要有两类：第一类是系统中存在大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长；第二类是因为类定义不能继承（如final类）

用多个具体装饰类来装饰同一对象，得到功能更为强大的对象。
4. 具体构件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体构件类和具体装饰类，在使用时再对其进行组合，原有代码无须改变，符合“开闭原则”。

缺点：

  1. 使用装饰模式进行系统设计时将产生很多小对象，这些对象的区别在于它们之间相互连接的方式有所不同，而不是它们的类或者属性值有所不同，同时还将产生很多具体装饰类。这些装饰类和小对象的产生将增加系统的复杂度，加大学习与理解的难度。
  2. 这种比继承更加灵活机动的特性，也同时意味着装饰模式比继承更加易于出错，排错也很困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为烦琐。

适用环境：

  1. 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
  2. 需要动态地给一个对象增加功能，这些功能也可以动态地被撤销。
  3. 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。不能采用继承的情况主要有两类：第一类是系统中存在大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长；第二类是因为类定义不能继承（如final类）
猫十二懿
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
设计模式 - 结构型设计模式小结
了解➔熟悉➔掌握➔精通
02-02 6万+
分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击http://www.captainbed.net Definition Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prot...
Android设计模式--装饰模式
袁震的博客
11-24 1337
千淘万漉虽辛苦，吹尽黄沙始到金
设计模式 - 结构型设计模式 - 装饰模式（Java）
热门推荐
了解➔熟悉➔掌握➔精通
03-23 3万+
分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击http://www.captainbed.net Definition Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subcla...
结构型设计模式——装饰器模式
庄小焱
11-12 934
装饰者模式(decorator pattern): 动态地将责任附加到对象上, 若要扩展功能, 装饰者提供了比继承更有弹性的替代方案。本博文介绍结构型设计模式的装饰器模式，帮助大家更好学习和了解软件设计模式，更好的读懂源码设计。
【设计模式】-装饰器模式
五行缺火
08-07 1375
首先，我们需要定义一个接口或抽象类，它定义了核心功能的方法。这个接口或抽象类是被装饰的对象的类型，也是装饰器对象的类型。接下来，我们定义一个装饰器类，它实现了相同的接口或抽象类，并且持有一个核心功能对象的引用。} }
设计模式 - 结构型模式_外观模式
小工匠
02-05 2万+
设计模式是解决程序中不合理、不易于扩展、不易于维护的问题，也是⼲掉⼤部分 ifelse 的利器，在我们常⽤的框架中基本都会⽤到⼤量的设计模式来构建组件，这样也能⽅便框架的升级和功能的扩展。但如果不能合理的设计以及乱⽤设计模式，会导致整个编程变得更加复杂难维护，也就是我们常说的: 反设计 、 过渡设计。⽽这部分设计能⼒也是从实践的项⽬中获取的经验，不断的改造优化摸索出的最合理的⽅式，应对当前的服务体量。外观模式也叫⻔⾯模式，主要解决的是降低调⽤⽅的使⽤接⼝的复杂逻辑组合。
结构型设计模式
m0_67550226的博客
06-09 1943
结构型设计模式是一种关注怎样组合类和对象以形成更大的结构，同时简化结构间的关系的设计模式。这些模式帮助确保系统部件间的独立性和可维护性。
结构型设计模式（7种）
qq_52793248的博客
12-14 3546
结构型设计模式（7种）
Java设计模式-结构型设计模式-适配器模式
Fatter$hday的博客
04-26 1267
Java设计模式- 结构型设计模式-适配器模式
设计模式 - 装饰模式
Circ
04-16 4153
什么是装饰模式？ 装饰模式又名包装(Wrapper)模式。装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。 适用范围 动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。不改变接口的前提下，增强所考虑的类的性能。 何时使用： 1）需要扩展一个类的功能，或给一个类增加附加责任。 2）需要动态的给一个对象增加功能，这些功能可以再动态地撤销。 3）需要增加一些基本功能的排列组合而产生的非常大量的功能，从而使继承变得 不现实。 角色构成
c++设计模式-结构型模式-装饰器模式
06-12
c++设计模式-结构型模式-装饰器模式；QT工程；c++简单源码； 装饰器（Decorator）模式的定义：指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式。
JAVA-设计模式-结构型模式-装饰模式
08-10
JAVA-设计模式-结构型模式-装饰模式
设计模式之结构型模式
12-15
在本文中，我们将深入探讨结构型设计模式，特别是桥接模式、适配器模式、装饰者模式和组合模式，以及它们在实际场景中的应用。 1. **桥接模式**： 桥接模式将抽象部分与实现部分分离，使得它们可以独立进行变化。...
设计模式2-结构型模式.doc
04-30
在本文中，我们将探讨几种结构型设计模式，包括适配器模式、桥接模式、外观模式、享元模式、代理模式和装饰器模式。 1. **适配器模式**： - 适配器模式用于连接两个不兼容的接口，使得原本不能一起工作的类可以...
设计模式--装饰者模式java例子
02-06
装饰者模式是软件设计模式中的一种结构型模式，它的主要目的是动态地给对象添加新的功能，而无需修改原有代码。在Java中，装饰者模式通常通过继承和组合来实现，它提供了一种比继承更灵活的方式来扩展对象的功能。...
设计模式实战：日志系统的设计与实现
qq_40254606的博客
07-26 398
通过本项目，我们综合应用了单例模式、适配器模式和桥接模式，解决了日志系统的设计需求。通过这些模式，我们实现了系统模块的解耦和灵活扩展，使得代码结构更加清晰、易于维护。
【设计模式】建造者模式
weixin_61144851的博客
07-23 922
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。：这些模式关注对象之间的组合和关系，旨在解决如何构建灵活且可复用的类和对象结构。：这些模式关注对象之间的通信和交互，旨在解决对象之间的责任分配和算法的封装。
设计模式-单例模式
最新发布
weixin_51722520的博客
07-27 62
单例设计模式
C# 设计模式分类
語衣的个人博客
07-23 889
创建型模式主要关注对象的创建过程，包括如何实例化对象，并隐藏实例化的细节。结构型模式主要关注类和对象的组合，以形成更大的结构。行为型模式主要关注对象之间的通信和职责分配。
"FlyWeight效果-软件设计模式—结构型模式讲义
Flyweight模式是一种软件设计模式，属于结构型模式之一。它的主要目的是通过对对象的状态进行分离，实现对内部状态的共享，从而节约存储空间。Flyweight模式与Composite模式结合使用的时候，可以作为叶子节点，而父...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

猫十二懿

你的支持就是写文章的动力!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值