# design_pattern **Repository Path**: nan651993/design_pattern ## Basic Information - **Project Name**: design_pattern - **Description**: 设计模式代码实例，整理测试 - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2021-01-13 - **Last Updated**: 2021-12-06 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # 设计模式 - -[**TechBookWebsite**](https://www.runoob.com/design-pattern/decorator-pattern.html) @简单工厂 Factory - @Builder Builder 提供组合套餐，返回一个套餐。 - 通过builder里面，预制好不同的内涵的，屏蔽内部实现，返回抽象结果。外界使用抽象即可 @享元模式 FlyWeight Pattern 容器化管理，减少实例创建。从而节省内存，spring容器类似思路 - 通过容器存储创建过的对象，获取的时候，从容器中尝试获取，没有获取到，创建后，放入容器并返回。共享容器资源 @门面模式 Facade Pattern 创建一个（门面接待员），提供统一服务接口暴露。 - 收集功能，整合在一起，然后通过方法来分发功能。提供统一入口，调用一批功能聚合 @观察者模式 Observers 主题+观察者，互引用，主题变化，调注册的观察者通知方法 - 创建一个主题，持有一个观察者容器，添加观察者时，假如容器。主题变化，notify中遍历并调用观察者的更新方法。 对于观察者创建的时候，指定主题，那么就可以在主题notify的时候到主题中获取变更内容。进行更新 @装饰者 Decorator - 意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。 主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。 何时使用：在不想增加很多子类的情况下扩展类。 如何解决：将具体功能职责划分，同时继承装饰者模式。 关键代码： 1、Component 类充当抽象角色，不应该具体实现。 2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。 应用实例： 1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。 2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。 优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。 缺点：多层装饰比较复杂。 使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销。 注意事项：可代替继承。 @责任链模式（Chain of Responsibility Pattern） 介绍 意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。 主要解决：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。 何时使用：在处理消息的时候以过滤很多道。 如何解决：拦截的类都实现统一接口。 关键代码：Handler 里面聚合它自己，在 HandlerRequest 里判断是否合适，如果没达到条件则向下传递，向谁传递之前 set 进去。 应用实例： 1、红楼梦中的"击鼓传花"。 2、JS 中的事件冒泡。 3、JAVA WEB 中 Apache Tomcat 对 Encoding 的处理，Struts2 的拦截器，jsp servlet 的 Filter。 优点： 1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。 缺点： 1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。 使用场景： 1、有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。 2、在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 3、可动态指定一组对象处理请求。 注意事项：在 JAVA WEB 中遇到很多应用。