9.装饰着模式

1.星巴克咖啡订单项目

  • 咖啡种类/单品咖啡:Espresso(意大利浓咖啡)、 ShortBlack、 LongBlack(美式咖啡)、 Decaf(无因咖啡)
  • 调料: Milk、 Soy(豆浆)、 Chocolate
  • 要求在扩展新的咖啡种类时,具有良好的扩展性、改动方便、维护方便
  • 使用OO的来计算不同种类咖啡的费用:客户可以点单品咖啡,也可以单品咖啡 + 调料组合

方案1:解决星巴克咖啡订单问题分析

  • Drink 是一个抽象父类,表示饮料
  • des 就是对咖啡的描述,比如咖啡的名字
  • cost() 方法就是计算费用, 在 Drink 类中做成一个抽象方法
  • Decaf 就是单品咖啡, 继承 Drink,并实现 cost() 方法
  • 问题:这样设计,会有很多类,当我们增加一个单品咖啡,或者一个新的调料,类的数量就会倍增,就会出现类爆炸
    在这里插入图片描述

方案2:解决星巴克咖啡订单

前面分析到方案 1 中,因为咖啡单品 + 调料组合会造成类的倍增,因此可以做改进,将调料内置到 Drink 类,这样就不会造成类数量过多。从而提高项目的维护性(如图)

说明:milk、soy、chocolate 可以设计为Boolean,表示是否要添加相应的调料
在这里插入图片描述方案 2 优缺点分析

  • 方案 2 可以控制类的数量,不至于造成很多的类
  • 在增加或者删除调味品种类时,代码的维护量很大
  • 考虑到用户可以添加多份调料时,可以将 hasMilk() 返回一个对应 int 整形值
  • 考虑使用装饰者模式

2.装饰者模式定义

  • 装饰者模式:动态的将新功能附加到对象上。在对象功能扩展方面,它比继承更有弹性,装饰者模式也体现了开闭原则(ocp)

  • 这里提到的动态的将新功能附加到对象和ocp原则,在后面的应用实例上会以代码的形式体现

    装饰者模式(Decorator)原理

  • 装饰者模式就像打包一个快递

    • 主体: 比如陶瓷、衣服 ,即 Component,被装饰者
    • 包装:比如报纸填充、塑料泡沫、纸板、木板,即 Decorator,装饰者
  • Component 主体类:比如类似前面的 Drink

  • ConcreteComponent:具体的主体,比如前面的各个单品咖啡

  • Decorator:装饰者,比如各调料,装饰者里面聚合了一个 Component 的具体实现类

  • 在如图的Component与ConcreteComponent之间,如果实现类 ConcreteComponent 有很多,还可以设计一个缓冲层,将共有的部分提取出来,抽象出一个缓冲层

在这里插入图片描述

3.装饰者模式解决咖啡订单

  • Drink类就是前面说的抽象类,即 Component 主体类
  • 由于单品咖啡种类较多,设计Coffee 抽象类作为缓冲层,Coffee 抽象层的实现类就是被装饰类,比如 ShortBlack、Decaf 等就是单品咖啡
  • Decorator 是一个装饰类,继承了 Drink 类,并且聚合了一个被装饰的对象(Drink obj),Decorator 的 cost() 方法进行一个费用的叠加计算
  • 各种调味品,比如 Chocolate、Milk、Soy 等,继承 Decorator 装饰类,聚合(装饰)了一个被装饰者
    在这里插入图片描述

Drink:即 Component 主体类,其中定了义一个抽象方法 cost(),用于计算订单费用


/**
 * @author compass
 * @version 1.0
 * @date 2021-07-08 14:11
 */
public abstract class Drink {

    public String des; // 描述
    private float price = 0.0f; // 价格

    // 计算费用的抽象方法,由子类来实现
    public abstract float cost();

    public String getDes() {
        return des;
    }

    public void setDes(String des) {
        this.des = des;
    }

    public float getPrice() {
        return price;
    }

    public void setPrice(float price) {
        this.price = price;
    }

}

Coffee:被装饰者的抽象父类,因为具体的单品咖啡品种太多,所以我们将 Coffee 抽象类作为缓冲层

/**
 * @author compass
 * @version 1.0
 * @date 2021-07-08 14:12
 */
public class Coffee  extends Drink{
    @Override
    public float cost() {
        return super.getPrice();
    }
}

Espresso、LongBlack、ShortBlack、DeCaf:被装饰者的具体实现类

/**
 * @author compass
 * @version 1.0
 * @date 2021-07-08 14:13
 */
public class Espresso extends Coffee {
    public Espresso() {
        setDes(" 意大利咖啡 ");
        setPrice(6.0f);
    }
}

 class LongBlack extends Coffee {
    public LongBlack() {
        setDes(" longblack ");
        setPrice(5.0f);
    }
}

 class ShortBlack extends Coffee {
    public ShortBlack() {
        setDes(" shortblack ");
        setPrice(4.0f);
    }
}

 class DeCaf extends Coffee {
    public DeCaf() {
        setDes(" 无因咖啡 ");
        setPrice(1.0f);
    }
}

Decorator:装饰者的抽象父类,该类实现了 Drink 接口,同时 Decorator 中聚合了一个 Drink 的具体实现类的对象,cost() 方法用于计算【装饰者(调味品) + 被装饰者(咖啡)】的费用

// 装饰者
public class Decorator extends Drink {

    private Drink obj; // 聚合一个单品咖啡(被装饰者)

    public Decorator(Drink obj) {
        this.obj = obj;
    }

    @Override
    public float cost() {
        // super.getPrice:调味品(装饰者)的价格
        // obj.cost():单品咖啡(被装饰者)的价格
        return super.getPrice() + obj.cost();
    }

    @Override
    public String getDes() {
        // des:调味品(装饰者)的描述信息
        // getPrice():调味品(装饰者)的价格
        // obj.getDes():单品咖啡(被装饰者)的信息
        return des + " " + getPrice() + " && " + obj.getDes();
    }

}

Chocolate、Milk、Soy:装饰者的具体实现类

/**
 * @author compass
 * @version 1.0
 * @date 2021-07-08 14:14
 */
//具体的Decorator, 这里就是调味品
public class Chocolate extends Decorator {
    public Chocolate(Drink obj) {
        super(obj);
        setDes(" 巧克力 ");
        setPrice(3.0f); // 调味品 的价格
    }
}

 class Milk extends Decorator {
    public Milk(Drink obj) {
        super(obj);
        setDes(" 牛奶 ");
        setPrice(2.0f);
    }
}

 class Soy extends Decorator {
    public Soy(Drink obj) {
        super(obj);
        setDes(" 豆浆  ");
        setPrice(1.5f);
    }
}

CoffeeBar:客户端,发出咖啡订单请求

/**  装饰者设计模式
 * @author compass
 * @version 1.0
 * @date 2021-07-08 14:14
 */
public class CoffeeBar {

    public static void main(String[] args) {
        // 装饰者模式下的订单:2份巧克力+一份牛奶+LongBlack

        // 1. 点一份 LongBlack
        Drink order = new LongBlack();
        System.out.println("LongBlack的费用=" + order.cost());
        System.out.println("LongBlack的描述=" + order.getDes());

        // 2. order 加入一份牛奶
        order = new Milk(order);
        System.out.println("order 加入一份牛奶 费用 =" + order.cost());
        System.out.println("order 加入一份牛奶 描述 = " + order.getDes());

        // 3. order 加入一份巧克力
        order = new Chocolate(order);
        System.out.println("order 加入一份牛奶 加入一份巧克力  费用 =" + order.cost());
        System.out.println("order 加入一份牛奶 加入一份巧克力 描述 = " + order.getDes());

        // 3. order 加入一份巧克力
        order = new Chocolate(order);
        System.out.println("order 加入一份牛奶 加入2份巧克力   费用 =" + order.cost());
        System.out.println("order 加入一份牛奶 加入2份巧克力 描述 = " + order.getDes());
        System.out.println("===========================");

        // 牛奶+无卡咖啡
        Drink order2 = new DeCaf();
        System.out.println("order2 无因咖啡  费用 =" + order2.cost());
        System.out.println("order2 无因咖啡 描述 = " + order2.getDes());

        order2 = new Milk(order2);
        System.out.println("order2 无因咖啡 加入一份牛奶  费用 =" + order2.cost());
        System.out.println("order2 无因咖啡 加入一份牛奶 描述 = " + order2.getDes());

    }

}

使用装饰者模式,程序的扩展性特别强,比如我们想添加一个新的单品咖啡种类:DefCafe,我们只需让此类继承 Coffee 抽象父类即可,其他部分的代码无须作任何修改

4.JDK IO流使用的装饰者设计模式

  1. InputStream 是(被)装饰者的抽象父类,类似我们前面讲的 Drink
    2.FileInputStreamInputStream 子类,为具体的被装饰者,类似我们前面的 DeCaf,LongBlack
  2. FilterInputStreamInputStream子类,为装饰者的抽象父类,类似我们前面 的 Decorator装饰者
  3. DataInputStreamFilterInputStream子类,为具体的装饰者,类似前面的 Milk,Soy 等
  4. FilterInputStream类中有protected volatile InputStream in;代码,即其中含有被装饰者
  5. 分析得出在jdk 的io体系中,就是使用装饰者模式
    在这里插入图片描述
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在信号处理领域,DOA(Direction of Arrival)估计是一项关键技术,主要用于确定多个信号源到达接收阵列的方向。本文将详细探讨三种ESPRIT(Estimation of Signal Parameters via Rotational Invariance Techniques)算法在DOA估计中的实现,以及它们在MATLAB环境中的具体应用。 ESPRIT算法是由Paul Kailath等人于1986年提出的,其核心思想是利用阵列数据的旋转不变性来估计信号源的角度。这种算法相比传统的 MUSIC(Multiple Signal Classification)算法具有较低的计算复杂度,且无需进行特征值分解,因此在实际应用中颇具优势。 1. 普通ESPRIT算法 普通ESPRIT算法分为两个主要步骤:构造等效旋转不变系统和估计角度。通过空间平移(如延时)构建两个子阵列,使得它们之间的关系具有旋转不变性。然后,通过对子阵列数据进行最小二乘拟合,可以得到信号源的角频率估计,进一步转换为DOA估计。 2. 常规ESPRIT算法实现 在描述中提到的`common_esprit_method1.m`和`common_esprit_method2.m`是两种不同的普通ESPRIT算法实现。它们可能在实现细节上略有差异,比如选择子阵列的方式、参数估计的策略等。MATLAB代码通常会包含预处理步骤(如数据归一化)、子阵列构造、旋转不变性矩阵的建立、最小二乘估计等部分。通过运行这两个文件,可以比较它们在估计精度和计算效率上的异同。 3. TLS_ESPRIT算法 TLS(Total Least Squares)ESPRIT是对普通ESPRIT的优化,它考虑了数据噪声的影响,提高了估计的稳健性。在TLS_ESPRIT算法中,不假设数据噪声是高斯白噪声,而是采用总最小二乘准则来拟合数据。这使得算法在噪声环境下表现更优。`TLS_esprit.m`文件应该包含了TLS_ESPRIT算法的完整实现,包括TLS估计的步骤和旋转不变性矩阵的改进处理。 在实际应用中,选择合适的ESPRIT变体取决于系统条件,例如噪声水平、信号质量以及计算资源。通过MATLAB实现,研究者和工程师可以方便地比较不同算法的效果,并根据需要进行调整和优化。同时,这些代码也为教学和学习DOA估计提供了一个直观的平台,有助于深入理解ESPRIT算法的工作原理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值