当前位置：首页 > news >正文

中国旅游网站模板线下营销推广方式有哪些

news 2025/8/13 22:18:21

中国旅游网站模板,线下营销推广方式有哪些,网站后台可改资料,网站返回500错误页面目录背景概述概念角色基本代码分析❀❀花样重难点聚合关系认贼作父和认孙做父客户端的优化及好处继承到设计模式的演变过程总结背景这是我第二次写装饰模式，这一次是在上一次的基础上进一步探究装饰模式，这一次有了很多新的感受和想法，也…

背景

这是我第二次写装饰模式，这一次是在上一次的基础上进一步探究装饰模式，这一次有了很多新的感受和想法，也多了很多趣味性的内容，读完一定让你觉得写代码原来这么有意思。还是简单介绍一下装饰模式的概念，如果想了解更基础更详细的内容，可以先读一下我的第一篇装饰模式的博客：设计模式之装饰模式–优雅的增强

概述

概念

装饰模式（Decorator Pattern）是一种结构型设计模式，动态地给一个对象添加一些额外的功能，就增加功能来说，装饰模式比生成子类更为灵活。
在这里插入图片描述
这张图今天将反复出现，先来对照概念来一一认识一下这上面的每一个类

角色

在装饰模式中，通常涉及以下几个重要角色（请对照概念和类图）：

抽象组件（Component）
抽象组件定义了被装饰对象和装饰对象的共同接口。
具体组件（Concrete Component）
具体组件是实现了抽象组件接口的类，它是装饰的目标对象（要增加额外职能的类）。
抽象装饰器（Decorator）
抽象装饰器是一个包含了与抽象组件相同接口的成员变量，并从抽象组件继承的类。它的职责是在调用原始对象之前或之后，执行额外的操作（增加的额外职能的父类）。
具体装饰器（Concrete Decorator）
具体装饰器是实现了抽象装饰器接口的类，它包装了具体组件，并可以在调用前后执行额外的操作（增加的具体的额外职能）。

总结一下:这种图昨天的类是要增加额外职能的类，右边一坨是要增加的额外职能。

打个比方，左边的具体组件（Concrete Component）和右边要增加的职能抽象装饰器（Decorator）本来毫不相干，但是现在非要把它们往一起凑（非要变成一家人），怎么办，那就找了一个义父（抽象组件（Component）），强硬的变成了一家人（同一个义父的子类）

基本代码分析

抽象组件：(定义的规范：子类如何实现的规范)

public interface Component {void operation();
}

具体组件：

public class ConcreteComponent implements Component {@Overridepublic void operation() {System.out.println("具体组件的操作");}
}

抽象装饰器：
这是关键类，里面一共三部分，一个Component 类型的属性，一个setComponent方法，用来给属性赋值，这里使用了多态，参数Component component，看起来接受的是一个Component 类型的变量，但是自始至终，接受的只是Component 的子类（ConcreteComponent ）和孙类（ConcreteDecoratorA 和ConcreteDecoratorB），用两个词语里形容就是 认贼作父和认孙做父！这个放到后面细说。第三部分是重写的父类方法，调的是传进来的Component类型的变量的operation方法。

public abstract class Decorator implements Component {protected Component component;public void setComponent(Component component) {this.component = component;}@Overridepublic void operation() {if (component != null) {component.operation();}}
}

具体装饰器A：
这两个具体的装饰类继承自Decorator ，同时也继承自Component （双层继承），这里的重点是operation方法中的super.operation();也就是这个方法让整个装饰的过程按照正确顺序串联起来。
ConcreteDecoratorA 中增加了一个属性，也就是给被装饰对象增加的额外职责。
ConcreteDecoratorB中增加了一个方法，给给装饰对象增加的额外职责。
这两个类算是从两个维度，告诉我们如何给被装饰对象增加额外职责的。

public class ConcreteDecoratorA extends Decorator {private String addedProperty;@Overridepublic void operation() {super.operation();addedProperty="New State";System.out.println("具体装饰器A的操作);}}

具体装饰器B：

public class ConcreteDecoratorB extends Decorator {@Overridepublic void operation() {super.operation();addedMethod();}public void addedMethod() {System.out.println("具体装饰器B的操作");}
}

客户端使用：

ConcreteComponent c= new ConcreteComponent();
ConcreteDecoratorA d1= new ConcreteDecoratorA();
ConcreteDecoratorB d2= new ConcreteDecoratorB();d1.setComponent(c);
d2.setComponent(d1);
ConcreteDecoratorB.operation();

客户端里先实例化了三个对象
第一对象C是要装饰的原有对象。
后面两个对象是具体的装饰对象。

重点来了：我来说一下下面代码的执行顺序，不要眨眼**

d1.setComponent ( c ) 这句代码执行的时候会先到ConcreteDecoratorA 类中，没有找到setComponent 方法，因此会向它的父类Decorator 中找，然后把C对象传递给Decorator 的component属性
同样，d2.setComponent(d1)执行的时候，会把装饰了C对象的d1对象传递给Decorator 的component属性。这里一定要注意是装饰了C对象的d1对象。

接下来，执行ConcreteDecoratorB.operation();
会先到ConcreteDecoratorB找到operation方法，这个方法里的第一句是super.operation();
在这里插入图片描述
是先执行父类Decorator 的operation方法，这个方法里先判空，然后执行component的operation，这个时候要注意，这个component是刚刚上面传进来的d1,

此时会d1是ConcreteDecoratorA 类型的，那又回到了ConcreteDecoratorA 中执行operation方法，接下来和刚才一样，执行父类Decorator 的operation方法，判空，然后执行component的operation，这个component是刚刚上面传进来的c，c是ConcreteComponent 类型，然后执行ConcreteComponent 里面的operation方法，打印“具体组件的操作”，后面就是一路返回，怎么来的怎么回去。

输出结果为：

具体组件的操作
具体装饰器A的操作
具体装饰器B的操作

❀❀花样重难点

聚合关系

还是这张图
红框框住的两部分，被装饰对象和具体装饰对象加起来是Component （儿子和孙子的抽象），也就是聚合关系的箭头所指，他们加起来聚合到了Decorator ，这是形式上的聚合，在代码中并没有体现（关于这一点还有待探究）
那么为什么不是Decorator自聚合呢，如果是自聚合，只是代表Decorator是具体装饰的容器，那么就不能把服饰包装到ConcreteComponent 上了
在这里插入图片描述
关于上面的解释在代码中的体现就是Decorator类中的Component 类型的参数

这里引出来我的下一个问题

认贼作父和认孙做父

Component 本来是Decorator的父类，但是在代码的实际运行中，传的只有ConcreteComponent 和ConcreteDecoratorA 和ConcreteDecoratorB。
ConcreteComponent 相对于Decorator来说是同辈份。（认贼作父）
ConcreteDecoratorA 和ConcreteDecoratorB都是Decorator的子类。（认孙做父）

客户端的优化及好处

在这里插入图片描述
这三段代码，可以看到引用都是子类型的，其实完全是可以用父类型去接
先问个问题，这三个实例都可以使用Component去接吗？
不要被迷惑住了，虽然他们都继承自Component，但是Component里可是没有setComponent方法的，所以只有new ConcreteComponent()可以用Component接。
代码可以改成:

Component c= new ConcreteComponent();
Decorator d1= new ConcreteDecoratorA();
Decorator d2= new ConcreteDecoratorB();

这样写有什么好处呢？
多客户端的复用
比如后两句都用Decorator 去接，=号右边完全可以使用配置文件，动态new对象，如果把没一句都看成一个按钮背后的逻辑，每个按钮都是一个客户端，放到页面上就实现了并行。重复的代码就可以使用自动生成。

继承到设计模式的演变过程

最后再说一个我自己的想法，仅供参考
还记得开头概念中说过的“就增加功能来说，装饰模式比生成子类更为灵活”，就先来说说继承，如果我们想给一个类增加功能，如果不在原有类中增加代码的话，可以使用继承的形式增加新的代码，那先看下面的图中左边的图，这个例子是设计模式书上的给人穿衣服的例子，如果不清楚，可以参照我的上一篇博客中的代码，链接在最上面。
加入TShirt是要给Person增加的功能，那么可以使用继承。左边的图。
那么根据封装变化点（这是面向对象的精髓），现在是增加了一个TShirt，我又想增加一个其他的类TShirt2，你会怎么做，会抽出一个父类，遵循依赖倒置原则，会让Person和接口Finery产生关系，就变成了右边的图
在这里插入图片描述

同样的道理，现在被装扮类不止一个Person,我也想给Animal装扮。那么就给Person和Animal抽出一个父类Component,遵循依赖倒置原则，会让Finery和接口Component产生关系，就变成了右边的图。现在看这张图和我开篇放的那张装饰模式的图是不是基本一致了，只是缺少了聚合关系。
关于聚合关系，在业务实现过程中并没有体现，这点以后有机会再研究。

在这里插入图片描述