划雨悦潭之赋的博客

设计模式是一把双刃剑，可以用来提升代码质量，但也可以提高代码复杂度，需要善加利用。具体问题具体分析，不能滥用也不能只用那么一两种，他们各有千秋，无法确定哪个设计模式最好，适合项目环境的才是最好的。

策略模式（Strategy Pattern）属于行为型设计模式，旨在维护多分支复杂逻辑时，每一个分支对应的类只需要关心自己内部的实现逻辑即可，无需关心是如何切换策略的。简而言之，一句话判断走哪个类，这个执行自己的行为。在传统的逻辑判断中，多一条分支会多写一条判断条件，当条件越来越多，就会产生大量if-else或者switch-case的灾难性代码块，如果新增一个新的条件，就需要在原逻辑上修改，严重违背了开闭原则。策略模式就是为了解决这个问题的，根本上就是要让实现逻辑和使用逻辑解耦分离。

模板模式是一种经典的抽象思想，旨在将一系列类似行为的共性行为抽出，作为抽象逻辑，个性行为会作为重写的个性呈现，这样有利于提取公共代码，减少重复逻辑。

发布订阅模式作为观察者模式的改良版，适合较为复杂的应用场景，前端最经典的应用就是Vue的数据双向绑定，Vue数据双向绑定的代码也会更加符合代码设计的艺术。

观察者模式是一种经典的设计思想，可以将观察者和被观察者之间耦合的逻辑进行解耦，使职责更加清晰，提高了代码的可维护性。

代理模式（Proxy Pattern）属于 结构型 设计模式。让真实的对象有个“替身”，当客户端访问系统时，其实是在访问这个“替身”，这个“替身”用来缓解真实对象的压力，解耦的同时也对性能有所提升。当外界不满足访问对象的要求时，需要代理模式对访问进行控制，提升系统的安全级别。所以代理对象可以帮真实对象进行过滤和筛选，当访问请求是符合条件的就放行，不符合条件的就过滤掉。

适配器模式可谓是经常用到，并且作为一种重要设计思想，能够提高代码的兼容性、扩展性和可维护性。

装饰器模式很好诠释了“组合”的思想，能够保证设计原则的同时也大大提高了客户端使用的便捷性，但也不要过度装饰和包装，可能导致太多层反而增加代码复杂度。

为了避免暴露创建对象具体的细节使用了简单工厂，但是存在工厂负担过重的问题，所以用标准工厂去解耦，形成一个产品一个工厂的局面；当有一组产品需要生产是使用抽象工厂，解决群组和系列生产的问题。

单例模式（Singleton Pattern）属于创建型设计模式，是经典设计模式中最简单的一种，也是开发中最常见的一种。顾名思义，单例可以理解为一个类有且仅有一个实例对象，每次创建实例对象时，如果存在实例则返回该实例。设计模式对于前端而言需要细细品味，多看一次多思考一次可能会有新的收获，无形中会改变你的编码思路，提高代码质量。