软件常见设计模式

设计模式

设计模式是为了解决在软件开发过程中遇到的某些问题而形成的思想。同一场景有多种设计模式可以应用，不同的模式有各自的优缺点，开发者可以基于自身需求选择合适的设计模式，去解决相应的工程难题。

良好的软件设计和架构，可以让代码具备良好的可读性、可维护性、可扩展性、可复用性，让整个系统具备较强的鲁棒性和性能，减少屎山代码出现的概率。

创建型模式

创建型设计模式提供了各种对象创建机制，增加了现有代码的灵活性和重用性。

工厂方法模式（Factory Method）：为超类提供了一个创建对象的接口，但允许子类改变将被创建的对象的类型。

优点：

良好的封装性。将产品的实例化封装执行，避免被修改，这样的产品具备良好的一致性。
良好的扩展性。增加产品时，同步增加一个工厂子类，不会违反开闭原则。
标准的解耦合框架。使用者只需要知道自己要什么产品即可，不用去管产品具体的特性等等，降低了模块间的耦合。

缺点：

代码量大。每加一个产品，都要加一个工厂子类，代码会显得臃肿。
不利于扩展复杂的产品结构。

抽象工厂模式（Abstract Factory）：允许您在不指定具体类的情况下生成一组相关对象的模式,相当于升级版的工厂模式。

优点：

具体类分离。具体产品类在具体工厂的实现中进行了分离和归类。
易于更换产品族。当客户想要改变整个产品族时，只需要切换具体工厂即可。
利于产品一致性。当产品族的各个产品需要在一起执行时，抽象工厂可以确保客户只操作同系列产品，而不会进行跨品牌的组合。

缺点：

不利于添加新种类产品。每加一个新的种类，如多一个项链类型的产品，那每一个具体工厂都要进行代码的扩展，且破坏了原先规定的结构，违反了开闭原则。

建造者模式（Builder）：允许您逐步构建复杂对象的模式。该模式允许您使用相同的构建代码生成不同类型和表示的对象。

优点：

封装性好。有效地封装了建造过程（主要业务逻辑），使得系统整体的稳定性得到了一定保证。
解耦。产品本身和建造过程解耦，相同的建造过程可以创建出不同的产品。
产品建造过程精细化。该模式注重产品创建的整个过程，将复杂的步骤拆解得到多个相对简单的步骤，使得系统流程更清晰，且对细节的把控更精准。
易于扩展。如果有新产品需求，只需要添加一个建造者类即可，不需要改动之前的代码，符合开闭原则。

缺点：

产品的组成部分和构建过程要一致，限制了产品的多样性。
若产品内部有结构上的变化，则整个系统都要进行大改，增加了后期维护成本。

原型模式（Prototype）：允许您复制现有对象而不使您的代码依赖于它们的类的模式。

优点：

便捷、简洁、高效。不需要考虑对象的复杂程度，只需要复制即可。
无需初始化。可动态地获取当前原型的状态，并在当前基础上进行拷贝。
允许动态增加或减少产品类。

缺点：

每个类都需要配备一个clone函数，若对已有的类进行改造，需要修改其源码，违背了开闭原则。

单例模式（Singleton）：单例模式是一种创建型的软件设计模式，在工程项目中非常常见。通过单例模式的设计，使得创建的类在当前进程中只有一个实例，并提供一个全局性的访问点，这样可以规避因频繁创建对象而导致的内存飙升情况。

结构型设计模式

结构型设计模式解释了如何将对象和类组合成更大的结构，同时保持这些结构的灵活性和高效性。

适配器模式（Adapter）：允许具有不兼容接口的对象进行协作的模式。

优点：

良好封装性。接口内的内容对使用者而言是透明的，即看不见，这确保了内部功能具备较好的封装性，不易被改动。
解耦。不匹配的两方在适配器的作用下可以做到解耦，不需要修改任何一方原有代码逻辑。
良好复用性。适配的两方不需要做任何修改，业务的实现可以通过适配器来完成，不同的业务可以使用不同的适配器。
良好扩展性。若要增加业务场景，只需要增加适配器类，来满足业务即可。

缺点：

不利于维护。因为业务的实现基于适配器完成，适配器中代码的复杂程度会越来越高，不熟悉业务或者底层逻辑的人难以短时间内接手维护。
系统结构易混乱。当业务量快速增加时，适配器类的数量也会快速增加，没有良好的系统架构布局，最终会使得整个系统臃肿且危险。

桥接模式（Bridge）：将一个大类或一组紧密相关的类分割成两个独立的层次结构（抽象和实现），使它们可以相互独立地进行开发的模式。

优点：

扩展性好。抽象与实现分离，扩展起来更便捷，可以获得更多样式的目标。
解耦。不同抽象间的耦合程度低。
满足设计模式要求的合成复用原则和开闭原则。
封装性好。具体实现细节对客户而言是透明不可见的。

缺点：

使用场景有限制。只有系统有两个以上独立变化维度时才适用。

复合模式（Composite）：将对象组合成树状结构，然后以与单个对象相同的方式处理这些结构的模式。

优点：

层次鲜明。凸显“部分-整体”的层次结构。
一致性。对叶子对象（单）和容器对象（组合）的操作具备良好一致性。
节点自由度高。在结构中按需自由添加节点。

缺点：

设计更抽象。
应用场景限制。

装饰器模式（Decorator）：将具有特定行为的对象放置在包含这些行为的特殊包装对象中，从而使您可以向对象附加新的行为的模式。

优点：

灵活性好。相比较继承，装饰模式扩展对象功能更加灵活。
扩展性好。不同装饰组合，可以创造出各式各样的对象，且避免了类爆炸。
满足设计模式要求的开闭原则和合成复用原则。
透明性好。客户端针对抽象操作，对具体实现的内容不可见。

缺点：

复杂性高。装饰模式的设计往往具备较高复杂度，对开发者的水平要求高。

外观模式（Facade）：为库、框架或任何其他复杂的类集合提供简化的接口的模式。

优点：

简洁易使用。为复杂的模块和系统提供了一个简单的接口，简易化操作。
保证了子系统独立性。子系统间独立性良好，彼此间一般不受影响，如何使用由门面决定。
保证了系统稳定性。当直接使用子系统，可能会出现无法预知的异常时，门面模式可通过高层接口规范子系统接口的调用，且有效阻隔子系统和客户端间的交互，进而增强系统鲁棒性。
隐秘性好。门面将子系统的具体细节都封装了起来。

缺点：