用dw做购票网站模板seo名词解释

设计模式分类

模板方法模式

核心就是设计一个部分抽象类。
这个类具有少量具体的方法，和大量抽象的方法，具体的方法是为外界提供服务的点，具体方法中定义了抽象方法的执行序列

装饰器模式

现在有一个对象A，希望A的a方法被修饰
实现思路：

1. 将A抽象成抽象类O
2. 装饰器类D来继承O，并聚合O
3. 装饰器类D的构造函数传参O，并赋值给所聚合的O
4. 装饰器类D可以不用实现a方法，保持抽象
5. 具体装饰类D1继承装饰器类D，新增修饰方法d1，然后再重写a方法，重写内部使用修饰方法d1并调用super.a
6. 具体装饰类D2继承装饰器类D，新增修饰方法d2，然后再重写a方法，重写内部使用修饰方法d2并调用super.a
7. ……
8. 使用时，新建原始对象A，把A传入D1构造器并再次用A接收，再把A传入D2构造器并再次用A接收，……于是实现了多重装饰（每一层装饰都对上层屏蔽了下层细节）

适配器模式

实现适配器之前：

实现适配器之后：
继承方式实现：

委托方式实现：

代理模式

代理模式和装饰器模式在作用上类似，不过代理模式侧重于缓解原对象的某些繁重的工作，而装饰器模式侧重于对原对象的某些行为进行修饰和控制

简单工厂、工厂方法、抽象工厂、建造者模式的对比

始终保持面向“产品”思考
当仅需要创造一类产品，且产品内部类别不多时，使用简单工厂模式：

当仅需要创造一类产品，但产品内部类别纷繁且多变时，使用工厂方法模式：

当需要创造多类产品，且产品内部类别纷繁且多变时，使用抽象工厂模式：（抽象工厂模式可以用来制造复杂的产品，“将关联零件组装成产品”）

在抽象工厂模式下，一个最终产品往往是由多个部分组成的，如上图中最终产品就是由产品A和产品B共同组成的，这就导致一个问题：可能由于客户端代码的编写疏忽而导致漏掉某一个部分。于是有了建造者模式：

建造者模式中新增了Director类，它就相当于一个“保险类”，在Director内部提前编写好没有遗漏任何一个部分的组装流程，然后暴露一个简单的SAP——construct方法直接由客户端调用，这样客户端就从如履薄冰的复杂构造过程中解放了出来，降低了出错的概率

组合模式

一句话精髓——容器与内容的一致性
最好的例子——文件和文件夹的例子

组合模式最特别的地方就是Composite类含有一个对抽象的Component的聚合

Flyweight模式，享元模式

Facade模式，外观模式

一句话总结——接口（API）变少了

Visitor模式，观察者模式

《图解设计模式》这本书太好了，一段话就能把一个设计模式的关键讲清楚：