# decorator

**Repository Path**: likeyang/decoratord

## Basic Information

- **Project Name**: decorator
- **Description**: 装饰器模式demo
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2023-02-17
- **Last Updated**: 2023-02-17

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

【设计模式实战】-使用装饰器模式优化复杂的商品价格的计算
https://blog.csdn.net/qq_32590703/article/details/106876667

    装饰器模式主要解决继承关系过于复杂的问题，通过组合来替代继承。它主要的作用是给原始类添加增强功能。这也是判断是否该用装饰器模式的一个重要的依据。除此之外，装饰器模式还有一个特点，那就是可以对原始类嵌套使用多个装饰器。为了满足这个应用场景，在设计的时候，装饰器类需要跟原始类继承相同的抽象类或者接口。

    每逢双十一，为了加大商城的优惠力度，开发往往要设计红包 + 限时折扣或红包 + 抵扣券等组合来实现多重优惠。而在平时，由于某些特殊原因，商家还会赠送特殊抵扣券给购买用户，而特殊抵扣券 + 各种优惠又是另一种组合方式。

  要实现以上这类组合优惠的功能，最快、最普遍的实现方式就是通过大量 if-else 的方式来实现。但这种方式包含了大量的逻辑判断，致使其他开发人员很难读懂业务， 并且一旦有新的优惠策略或者价格组合策略出现，就需要修改代码逻辑，代码扩展性不强，不能满足开闭原则。

  此项目通过装饰器模式实现了一个复杂的商品计算策略，每个优惠信息都是单独的一个类，装饰类和被装饰类都只关心自身的业务，不相互干扰，真正实现了解耦。同时还优化了业务代码的结构设计，使得整个业务逻辑清晰、易读易懂。

  此外我们还可以动态的来进行组合各种优惠信息，之后如果新增一个优惠类型也不会对存量的优惠信息影响，只需新实现一个继承了BaseCountDecorator的类即可，满足了对扩展开放，对修改关闭的原则。