装饰模式

定义： 在不必改变原类文件和原类使用的继承的情况下，动态地扩展一个对象的功能。 它是通过创建一个包装对象，也就是用装饰来包裹真实的对象来实现。 //抽象对象，公共对象 public interface Person { public void eat(); } //被装饰对象 public class OldPerson implements Person { public void eat() { System.out.println("吃饭"); } } //装饰对象 public class NewPerson implements Person { private OldPerson oldPerson; public NewPerson(OldPerson oldPerson) { this.oldPerson = oldPerson; } public void eat() { System.out.println("生火"); System.out.println("做饭"); oldPerson.eat(); System.out.println("刷碗"); } } //测试类 public class Test { public static void main(String[] args) { NewPerson newPerson = new

结构型模式 装饰器模式 允许向一个现有的对象 添加新的功能 ，同时又 不改变 其结构 注：这句话要深入理解可看 https://www.cnblogs.com/volcano-liu/p/10897897.html 中汉堡包的例子 注：设计模式不一定单独使用，可以混合使用，比如上图的咖啡就可以是工厂模式下的到的咖啡 代理模式 当一个对象不适合或者不能直接引用另一个对象，为其他对象提供一种 代理 以控制对这个对象的访问 结构相似但还是有区别： 目的不同 装饰器增强自身（第三方是我内部），代理是找经纪人（外部） 依赖不同 代理类依赖委托类，装饰角色依赖更灵活点 java有三种代理，用法可参考 https://www.cnblogs.com/jie-y/p/10732347.html 为什么可以得看源码 来源： CSDN 作者： a_higher 链接： https://blog.csdn.net/a_higher/article/details/104554581

一、装饰者模式的应用场景 在我们的生活中比如给煎饼加个鸡蛋，给蛋糕加上一些水果，给房子装修等。为对象扩展一些额外对象的职责。装饰者模式（Decorator Pattern）是指在不改变原有对象的基础之上，提供了比继承更有弹性的替代方案（扩展原有对象的功能）。 装饰者模式使用于以下几种场景： 用于扩展一个类的功能或给一个类添加附加职责； 动态的给一个对象添加功能，这些功能可以动态的撤销。 1.1 🌮 早餐吃煎饼的装饰者模式 在北京早上通勤上班的同学们，都有吃过路边摊的煎饼吧。买煎饼的时候可以让他给你加个鸡蛋，也可以加香肠，还可以加辣条等。下面我们用代码来实现下这个生活场景的案例，首先创建一个煎饼 BatterCake 类： public class BatterCake { protected String getMsg() { return "煎饼"; } protected BigDecimal getPrice() { return new BigDecimal(6.00); } } 再创建一个加鸡蛋的煎饼 BatterCakeWithEgg 类： public class BatterCakeWithEgg extends BatterCake { @Override protected String getMsg() { return super.getMsg() +

装饰者模式优点 ： 解决了继承带来的类爆炸问题 装饰模式允许系统动态装饰，继承关系则是静态的 装饰类可以排列组合，很灵活 可以对实现了共同接口的 方法进行增强 装饰者模式缺点 ： 装饰类很多以后，需要很多的对象，占用内存空间，关系较为复杂，尤其在多层包装之后 应用： JAVAIO流中对流的包装。 数据库连接池中对connection，close方法的包装，由原来的close方法变为重新加入到连接池。 图片来源于： https://blog.csdn.net/dhka8040652/article/details/101460102?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task 来源： CSDN 作者： MchBeg 链接： https://blog.csdn.net/cole2295/article/details/104541416

一、简介 1、概念 装饰模式又名包装模式，对客户端以透明的方式扩展对象的功能，是继承关系的一个替代方案。 但是大部分装饰模式都是半透明的<介于装饰模式和适配器模式直接>，允许装饰模式改变接口，增加方法。 2、应用场景 动态地给一个对象添加一些额外的职责。装饰模式相比继承更为灵活。不改变接口的前提下，增强所考虑的类的性能。 1）需要扩展一个类的功能，或给一个类增加附加责任。 2）需要动态的给一个对象增加功能，这些功能可以再动态地撤销。 3）需要增加一些基本功能的排列组合而产生的非常大量的功能，从而使继承变得不现实。 3、角色 l 抽象构件(Component)角色：给出一个抽象接口，以规范准备接收附加责任的对象 l 具体构件(ConcreteComponent)角色：定义一个将要接收附加责任的类 l 装饰角色(Decorator)：持有一个构件(Component)对象的实例，并定义一个与抽象构件接口一致的接口 l 具体装饰角色(ConcreteDecorator)：负责给构件对象“贴上”附加的责任 二、举例说明 咖啡是一种饮料，咖啡的本质是咖啡豆+水磨出来的。咖啡店现在要卖各种口味的咖啡，如果不使用装饰模式，那么在销售系统中，各种不一样的咖啡都要产生一个类，如果有4中咖啡豆<构件>，5种口味<装饰>，那么将至少20个类。使用了装饰模式，只需要11个类即可生产任意口味咖啡

我在装饰器传递变量'insurance_mode'时遇到问题。 我可以通过以下装饰器语句来做到这一点： @execute_complete_reservation(True) def test_booking_gta_object(self): self.test_select_gta_object() 但不幸的是，该声明不起作用。 也许也许有更好的方法来解决此问题。 def execute_complete_reservation(test_case,insurance_mode): def inner_function(self,*args,**kwargs): self.test_create_qsf_query() test_case(self,*args,**kwargs) self.test_select_room_option() if insurance_mode: self.test_accept_insurance_crosseling() else: self.test_decline_insurance_crosseling() self.test_configure_pax_details() self.test_configure_payer_details return inner_function #1楼 编辑 ：要深入了解装饰者的心理模型，请看一下

一 单例模式 ： 解决的问题：就是可以保证一个类在内存中的对象唯一性。 public class SingleInstance { private static volatile SingleInstance singleInstance = null; private SingleInstance() { } public SingleInstance getInstance() { if (singleInstance == null) { //A synchronized (SingleInstance.class) { if (singleInstance == null) { singleInstance = new SingleInstance(); //B } } } return singleInstance; } } Note 1:添加volatile修饰避免B处指令重排序时其他线程拿到B处可能还未初始化的单例对象（完成了内存分配，引用的赋值 还未来得及进行对象的初始化）然后在A处判断单例对象不为空直接返回的未初始化的对象。 Note 2: synchronized关键字保证了临界区内变量的可见性和原子性，但无法保证临界区之外访问的变量的原子性。如果对单例对象的读写完全在临界区内，那么就不会出现线程安全问题。不过，这样就带来了性能问题。 Note 3

设计模式-装饰器模式 定义 动态的给一个对象添加一些额外的职责。从功能上来说，类似于子类扩展父类，但装饰器模式更加灵活（可以独立于需要扩展的组件） UML 优点 独立于被扩展的组件独立发展，不耦合 替代继承 动态灵活的实现按照多层、组合、顺序、的封装 缺点 过多层的装饰难于理解，剥开层层装饰才能看到最里层，不好排查问题，不易阅读 实现 Component 组件 public interface Report { void report(); void reviews(String reviewsResult); } ConcreteComponent public class YearSummaryReport implements Report { @Override public void report() { System.out.println("今年销售额 一千万"); } @Override public void reviews(String reviewsResult) { System.out.println("报告点评: " + reviewsResult); } } AbstraceDecoretor public abstract class Decorator implements Report { private Report report;

//设计模式 //创建型设计模式：关注对象的创建 //结构型设计模式 ：关注类鱼类之间的关系 // 组合优于继承，装饰器模式是组合+继承 //行为型设计模式 ：关注对象和行为分离 //类与类之间的关系 //1.纵向关系 继承--实现 //2.横向关系： 聚合、组合、包含、依赖 //组合优于继承（横向优于纵向） // 继承： 为了代码重用，通过继承覆写，不修改原有类，增加了新功能，代码简单 // // 组合：通过构造函数把本来要继承实现的对象传递进去 // 组合完成了功能扩展，不修改原有类，需实例化两个类，代码更复杂 // 面向对象，不仅为一个类型服务，解耦合 1. 概念 装饰器模式 允许向一个现有的对象添加新的功能，同时又不改变其结构。装饰者可以在所委托被装饰者的行为之前或之后加上自己的行为，以达到特定的目的。 2. 组成 装饰器模式由组件和装饰者组成。抽象组件（Component）：需要装饰的抽象对象。 具体组件（ConcreteComponent）：是我们需要装饰的对象 抽象装饰类（Decorator）：内含指向抽象组件的引用及装饰者共有的方法。 具体装饰类（ConcreteDecorator）：被装饰的对象。 3. 优缺点 优点 ： 可以动态的扩展功能； 装饰者和被装饰者解耦，互相不关联。 缺点： 多层装饰比较复杂。 装饰者模式的适用场景： 扩展一个类的功能；

一． 适配器模式 配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。这个模式将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 实现方式是，适配器继承或依赖已有的对象，实现想要的目标接口。 需要注意的是: 适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。 二． 桥接模式 桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。 桥接模式将继承关系转换为关联关系，并且这种关联关系是建立在抽象层，从而降低了类与类之间的耦合，减少了代码编写量。 例子：画图，这里有一个画笔，可以画正方形、长方形、圆形（这个大家都知道怎么做吧，我就不解释了）。但是现在我们需要给这些形状进行上色，这里有三种颜色：白色、灰色、黑色。这里我们可以画出3*3=9中图形：白色正方形、白色长方形、白色圆形……，到这里了我们几乎到知道了这里存在两种解决方案：方案一：为每种形状都提供各种颜色的版本。方案二：根据实际需要对颜色和形状进行组合。 使用场景：1、如果一个系统需要在构件的抽象化角色和具体化角色两者之间增加更多的灵活性