代理模式（Proxy Pattern）是一种结构型设计模式，它充当了另一个对象的接口，以控制对这个对象的访问。
代理模式的核心思想是通过引入一个代理对象来间接访问另一个对象，从而可以在访问这个对象时添加一些额外的控制逻辑，比如权限验证、缓存、延迟加载等。代理模式可以帮助我们在不改变原始对象的情况下，对其进行控制和扩展。
在日益追求高效与解耦的现代软件工程实践中，代理模式的应用愈发广泛。从Web服务中的远程代理，到大数据处理中的虚拟代理，再到日常编程中的智能指针，代理模式的身影无处不在。特别是在需要对对象的访问进行控制和扩展的情况下，代理模式可以提供一种灵活的解决方案。
然而，正如所有强大的工具一样，代理模式也不是没有代价。它可能会增加系统的复杂性，使得代码的理解和调试变得更加困难。因此，何时使用代理模式，以及如何正确地使用它，成为了每位软件工程师必须审慎考虑的问题。
Provide a surrogate or placeholder for another object to control access to it.
为另一个对象提供代理或占位符以控制对其的访问。
在软件开发的世界里，效率和资源利用率始终是开发者们追求的重要目标。随着系统规模的不断扩大，如何优化内存使用、提升性能，成为设计模式中不可忽视的一环。享元模式，以其独特的视角，为这一目标提供了一种精巧的解决方案。
享元模式源于对共享和复用机制的深刻洞察。它通过共享相似或相同的数据，减少对象创建的数量，从而降低内存占用，提高系统性能。这种模式尤其适用于那些具有大量相似对象的应用场景，如文档编辑、游戏开发等。
然而，享元模式并非银弹，它也有其适用的条件和局限性。在追求高效与节约的同时，我们不得不面对系统的复杂性增加、代码维护难度提高等挑战。因此，深入了解和合理运用享元模式，对于软件工程师来说，既是一项必备的技能，也是一次对设计原则和工程实践的全面考验。
接下来，让我们一同探索享元模式的奥秘，从概念的剖析到实际应用的演绎，从优点的展现到缺点的反思，全方位地理解这一设计模式的精髓，以便在软件开发的道路上，更加从容和明智地前行。
Use sharing to support large numbers of fine-grained objects efficiently.
运用共享技术有效地支持大量细粒度的对象。
外观模式（Facade Pattern）是一种结构型设计模式，它提供了一个简单的接口，隐藏了一个系统更大和更复杂的一部分的复杂性，从而使系统更易于使用。
外观模式的核心思想是为子系统提供一个统一的接口，以便客户端可以更容易地使用这些子系统。通过外观模式，客户端可以通过一个简单的接口来访问系统的各种功能，而不需要了解系统内部的复杂逻辑和实现细节。
这种模式在许多软件开发场景中都有实际应用，特别是在需要简化复杂系统接口的情况下，外观模式可以帮助减少系统之间的耦合，并提供更清晰的界面供客户端使用。
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level
interface that makes the subsystem easier to use.
为一个子系统中的一系列接口提供一个统一的接口。外观定义了一个更高级别的接口以便子系统更容易使用。
在软件开发的实践中，我们常常需要为对象添加新的功能，但有时候并不希望直接修改对象的原始类。直接修改原始类可能会引入不必要的依赖和耦合，增加系统的复杂性，同时也可能影响到其他使用该类的模块。那么，有没有一种方式可以灵活地给对象添加功能，而不改变其接口和继承结构呢？
面对这一问题，装饰模式（Decorator Pattern）提供了一个优雅的解决方案。装饰模式是一种结构型设计模式，它允许用户向一个现有的对象添加新的功能，同时又不改变其结构。这种模式通过创建一个包装对象，即“装饰者”，来包裹真实对象，并在保持原有对象方法签名不变的前提下提供额外的功能。
就像咖啡店里你可以根据个人喜好添加不同的调料和配料来定制你的咖啡一样，装饰模式允许我们在运行时动态地为对象添加“调料”，让其味道更加丰富。这种模式特别适合于场景复杂、需求多变的系统开发，因为它提供了极大的灵活性和扩展性。
接下来，我们将深入探讨装饰模式的结构、实现以及在实际开发中的应用案例，从而更好地理解这一设计模式如何帮助我们实现功能的动态扩展，使得软件系统更加灵活、易于维护和扩展。
Attach additional responsibilities to an object dynamically. Decorators provide a flexible
alternative to subclassing for extending functionality.
动态的为对象附加额外的职责。装饰器为子类提供了灵活的替代方案，以扩展功能。
桥接模式是一种结构型设计模式，它旨在将抽象部分与实现部分分离，从而使它们可以独立地变化。这种模式通过使用组合而不是继承的方式，可以在抽象和实现之间建立一座桥梁，使得它们可以独立地变化而互不影响。
在桥接模式中，抽象部分包含一个指向实现部分的引用，而实现部分则包含一个指向抽象部分的引用。这种结构使得抽象部分和实现部分可以各自独立地进行扩展和变化，而不会相互影响。
Decouple an abstraction from its implementation so that the two can vary independently.
将抽象与其实现分离，以便二者可以独立变化。
组合模式是一种结构型设计模式，用于将对象组合成树形结构以表示"部分-整体"的层次关系。这种模式使得客户端对单个对象和组合对象的使用具有一致性，从而无需关心处理的是单个对象还是整个对象树。组合模式常常用于处理树形结构的数据，例如文件系统、HTML文档结构，XML文档结构、组织架构等。通过使用组合模式，可以简化对复杂结构的操作，同时也提高了代码的可扩展性和可维护性。
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients
treat individual objects and compositions of objects uniformly.
将对象组合成树结构以表示部分整体层次结构。 组合可以使客户统一对待单个对象和组合对象。
在软件开发的世界中，我们经常会遇到一个棘手的问题：随着系统的发展与迭代，新功能的需求不断涌现，而这些新功能往往需要与旧有系统进行交互。这就带来了一个挑战——新旧系统之间由于接口不兼容、数据格式不同或是通信协议有所差异等问题，导致无法直接协同工作。如何让这些原本因接口或功能不匹配的组件能够无缝对接，共同完成任务？
面对这一问题，适配器模式（Adapter Pattern）应运而生。适配器模式是一种结构型设计模式，它通过引入一个中间层——即“适配器”——来解决两个不兼容接口之间的矛盾。这个适配器充当转换器的角色，将一种接口转换成另一种客户端期望的接口，从而实现了原有功能的新用途。
就像电源插头与插座的关系一样，虽然电源插头的形状各异，但只要使用对应的转换器，就可以在不同标准的电源插座中供电。在软件设计中，适配器模式允许已有的类或模块通过引入适配器来复用，而无需修改原有代码，大大增强了系统的灵活性和可扩展性。
Convert the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.
将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
单例模式，顾名思义就是在程序运行期间，一个类只有一个实例。
使用场景：需要在系统中确保类只有一个实例，一般这种类的创建都会比较占用系统资源。比如配置文件初始化，将配置文件中的数据读取到类中，通常需要耗费一定的系统资源，而且配置文件中的内容一般都是不变的，修改完配置文件一般都会要求重启系统。所以这种类最适合使用单例模式。
Ensure a class only has one instance, and provide a global point of access to it.
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
现在一般大型的业务系统中的消息通知的形式都会有多种，比如短信、站内信、钉钉通知、邮箱等形式。虽然信息内容相同，但是展现形式缺不同。如短信使用的是纯文本的形式，钉钉使用的一般是Markdown的形式，而邮箱则使用HTML形式。那如何处理这种差异呢？
建造者模式就是一个很好的选择，使用不同的建造者，来构造不同的消息。
建造者模式（Builder Pattern）是一种创建型设计模式，它可以让你构建复杂对象时更加灵活和可控。这种模式的主要目的是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
在软件开发中，我们经常会遇到一些复杂的对象，这些对象通常由多个部分组成，而且每个部分的创建和组合可能需要花费大量的时间和精力。为了解决这个问题，我们可以使用建造者模式来简化对象的构建过程。
建造者模式的核心思想是将复杂对象的构建过程分解为多个简单的步骤，每个步骤负责创建一个特定的部分。这些步骤被封装在一个单独的类中，称为“建造者”（Builder）。通过这种方式，我们可以逐步构建复杂对象，同时保持代码的可读性和可维护性。
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
对象池模式（Object Pool Pattern）是一种创建一组可重用对象的设计模式。它通过维护一个预分配的对象集合，避免了频繁地创建和销毁对象所带来的性能开销。在需要使用对象时，可以直接从池中获取，而不需要每次都创建新的对象；当对象不再使用时，可以将其归还到池中，而不是直接销毁。
对象池模式的主要优点是减少了对象的创建和销毁的开销，提高了程序的性能。此外，它还有助于控制资源的使用，避免资源的浪费。然而，对象池模式也有一些缺点，如增加了代码的复杂性，以及可能导致内存占用过高。
对象池模式并不是GoF中的23种设计模式
When objects are expensive to create and they are needed only for short periods of time it is advantageous to utilize the Object Pool pattern. The Object Pool provides a cache for instantiated objects tracking which ones are in use and which are available.
当对象的创建成本很高并且只在很短的周期内使用，那么对象池模式就很有优势。对象池提供一个对象示例的缓存来跟踪那个对象正在使用，哪个对象是可用的。