码事漫谈

设计模式专栏目录导航

本文为设计模式连载文章，其中讲解了设计模式基本原则，设计模式详细分类，设计模式的应用案例等，更多内容关注后可在设计模式专栏内查看。

UML（Unified Modeling Language，统一建模语言）中的类图（Class Diagram）是一种静态结构图，它用于展示系统中的类（class）、接口（interface）、协作（collaboration）以及它们之间的静态结构和关系。

依赖注入是一种设计模式，通过将类的依赖项通过构造函数、属性或方法传入，而不是类自己创建依赖对象。

简单工厂模式是一种结构简单但实用的设计模式，适合用于需求变化不频繁的小型项目或模块中，更多内容完善了简单工厂模式的局限性及改进方案，并扩展了实际应用案例，展示了模式的灵活性和变体的实现方法。但在扩展性要求高的场景中，推荐使用工厂方法模式或抽象工厂模式以增强灵活性。

工厂方法模式提供了更高的扩展性和灵活性，适合复杂或动态变化的产品族。它的实现复杂度较高，不适合产品种类固定或单一的场景。在实际项目中，工厂方法模式常与依赖注入、简单工厂、抽象工厂模式结合使用，以实现更加灵活的设计架构。本文为连载文章，更多内容关注后可在设计模式专栏内查看。觉得文章不错，记得，有任何问题欢迎评论探讨。

抽象工厂模式非常适合产品族场景，能很好地保证产品间的兼容性。但在产品种类频繁变化的情况下，其扩展性受到限制。通过结合其他模式（如单例、建造者），可以进一步提升其灵活性和实用性。本文为连载文章，更多内容关注后可在设计模式专栏内查看。觉得文章不错，记得，有任何问题欢迎评论探讨。

原型模式（Prototype Pattern）是一种创建型设计模式，它允许通过复制已有对象来创建新对象，而不是直接通过实例化类来创建。这种模式提供了一种创建对象的快捷方式，尤其适用于对象创建成本高或需要深复制的场景。原型模式通过复制已有对象，提供了一种高效的对象创建方式，适合对象初始化开销高或需要频繁复制的场景。其核心在于克隆方法的实现，正确处理深浅复制关系是关键。在实践中，原型模式通常与其他模式结合使用，如工厂模式、注册表模式，进一步提高代码的灵活性和复用性。欢迎！更多系列内容可以点击专栏目录。

建造者模式非常适合构造复杂对象，并使构建过程具有可扩展性和灵活性。它通过分离构建步骤和产品表示，解决了对象创建的复杂性问题。在实际开发中，建造者模式可以结合工厂模式和原型模式实现更复杂的功能，尤其是在配置生成、产品装配等场景中应用广泛。

观察者模式（Observer Pattern）是一种行为型设计模式，用于定义对象间的一对多依赖关系，使得当一个对象的状态发生变化时，所有依赖于它的对象都会自动收到通知并更新。这种模式主要用于实现发布-订阅机制。观察者模式是一种非常重要的行为型设计模式，它非常适用于需要在某些事件发生时通知多个对象的场景。它具有高灵活性和可扩展性，在许多系统中都可以找到它的身影，尤其是在事件驱动和消息发布-订阅系统中。使用观察者模式时，需注意管理观察者的生命周期，并避免频繁的状态更新导致性能问题。欢迎！更多系列内容可以点击。

应用场景：适配器模式适用于系统接口不兼容，但必须协同工作的场景。实现选择：类适配器在需要直接继承的情况下使用，对象适配器适用于松耦合场景。灵活性：适配器可以动态适配多个不同的接口，从而提供更灵活的解决方案。关键点：实现中要注意目标接口与适配者接口之间的功能映射关系，以避免错误适配。

桥接模式是一种结构型设计模式，旨在将抽象部分与实现部分分离，使它们可以独立地变化。通过这种方式，桥接模式减少了抽象和实现之间的依赖，提供了更高的灵活性和扩展性。桥接模式用于将抽象和实现解耦，让它们可以独立变化。适用于系统的功能和实现各自有多个变化维度的情况。提高扩展性和灵活性：通过桥接模式，系统可以灵活地扩展功能或实现，不会相互影响，减少了继承带来的复杂性。使用场景：广泛应用于跨平台开发、硬件抽象、图形系统等场景。

组合模式是一种结构型设计模式，它将对象组织成树形结构以表示“部分-整体”的层次结构，使客户端对单个对象和对象组合的使用具有一致性。组合模式的关键：将单个对象和组合对象统一为树形结构，提供一致的操作方式。使用时注意：合理管理子节点，避免误操作导致结构混乱。典型应用：文件系统、GUI组件树、组织架构。组合模式通过分层和组合，极大地提高了系统处理树形结构的能力，同时也对客户端代码的实现进行了很好的封装和抽象。欢迎！更多系列内容可以点击专栏目录祉猷并茂，顺遂无虞！

装饰模式是一种结构型设计模式，允许动态地向对象添加新功能，而不会影响其他对象。装饰模式通过使用一系列装饰类，将额外的行为或责任以层叠的方式附加到对象上。动态扩展功能：装饰模式适合在运行时灵活地扩展对象行为。避免类爆炸：通过装饰类组合，取代大量子类的设计。推荐场景：需要动态变化的系统功能，且遵守开放-封闭原则的设计要求。欢迎！更多系列内容可以点击专栏目录祉猷并茂，顺遂无虞！若将文章用作它处，请一定注明出处，商用请私信联系我！

外观模式是一种结构型设计模式，为子系统中的一组接口提供一个一致的接口。外观模式定义了一个高层接口，使得子系统更易于使用。高层接口：外观模式简化了复杂子系统的使用。降低耦合：实现了客户端与子系统的解耦。推荐场景：适用于隐藏复杂实现逻辑，统一接口调用的场景。欢迎！更多系列内容可以点击专栏目录祉猷并茂，顺遂无虞！若将文章用作它处，请一定注明出处，商用请私信联系我！

享元模式是一种结构型设计模式，旨在通过共享对象来尽量减少内存的使用。享元模式通过将重复使用的对象分离成共享和非共享部分，达到复用的目的，从而有效节省内存。内存优化：享元模式通过共享对象，显著减少内存占用。高效的对象管理：通过享元工厂管理共享对象的生命周期，避免不必要的对象创建。适用场景：大量相似对象的场景，尤其是在需要节省内存时。欢迎！更多系列内容可以点击专栏目录祉猷并茂，顺遂无虞！若将文章用作它处，请一定注明出处，商用请私信联系我！

代理模式：代理为真实对象提供了一个间接访问的方式，方便控制权限或扩展功能。实现灵活：代码可以根据需要添加日志、延迟加载或权限控制等功能。理解方法：通过生活例子结合实际代码，代理模式的作用更加直观。

策略模式灵活性高：可以轻松地添加新策略，扩展性好。职责清晰：将算法逻辑封装在独立的策略类中，简化了上下文的代码。场景适配：非常适合需要动态切换行为或算法的场景，比如支付系统、导航系统等。注意点：避免类爆炸（策略类过多），并且客户端需要了解可用策略的功能。

模板方法模式是一种行为型设计模式，定义一个操作中的算法骨架，将某些步骤的实现延迟到子类。通过模板方法，子类可以在不改变算法结构的情况下重新定义算法的某些步骤。模板方法就像烹饪中的食谱，它定义了做菜的步骤（算法骨架），而每道菜的具体细节（比如调味方式）由厨师（子类）决定。这样既保证了流程的一致性，又允许定制化。适用范围：当多个类具有相似的操作流程，且部分步骤需要定制时，使用模板方法模式非常合适。设计哲学：使用“模板”将不变的部分抽象出来，同时开放定制点以支持扩展。注意事项。

迭代器模式是一种行为型设计模式，用于提供一种顺序访问集合对象元素的方法，而不暴露集合的内部表示。通过迭代器模式，用户可以独立于集合的实现来遍历集合。迭代器就像一份菜单上的翻页工具，它不关心菜单的内容是如何存储的，只负责让顾客按顺序查看菜单上的菜品。当需要以一致的方式遍历不同类型集合时，可以使用迭代器模式。分离集合的遍历逻辑和集合的实现，增强灵活性。对于性能敏感的场景，需注意迭代器的内存开销。欢迎！更多系列内容可以点击专栏目录祉猷并茂，顺遂无虞！若将文章用作它处，请一定注明出处，商用请私信联系我！

责任链模式是一种行为型设计模式，它允许多个对象都有机会处理请求，而无需请求的发送者知道具体哪个对象会处理。将这些对象连成一条链，沿着这条链传递请求，直到有对象处理它为止。想象一个公司中请假审批的过程，员工的请假单会沿着一个审批链，从主管到经理再到总监，直到某个人批准或拒绝为止。当请求可能被多个对象处理，且不需要显式指定处理者时。灵活性高，降低耦合，易于扩展。责任链过长可能导致性能问题，需合理设计链的长度和顺序。欢迎！更多系列内容可以点击专栏目录祉猷并茂，顺遂无虞！

命令模式是一种行为型设计模式，它将一个请求封装为一个对象，从而使得可以用不同的请求对客户进行参数化、对请求排队或记录日志，以及支持可撤销的操作。将操作（请求）抽象成独立的对象，从而分离请求的发送者和接收者，允许轻松添加、修改和管理请求。当需要参数化请求、支持撤销操作、记录操作日志时，适合使用命令模式。解耦发送者和接收者，支持撤销与恢复操作，扩展性强。不要因滥用模式而增加系统复杂度，仅在需要时使用。欢迎！更多系列内容可以点击专栏目录祉猷并茂，顺遂无虞！

备忘录模式（Memento Pattern）是一种行为设计模式，用于在不暴露对象内部状态的情况下，捕获并存储对象的当前状态，以便日后可以将对象恢复到存储的状态。备忘录模式可以有效地实现撤销/恢复操作。

状态模式（State Pattern）是一种行为设计模式，它允许一个对象在其内部状态改变时改变其行为，使其看起来像改变了自身的类。通过将状态相关的行为抽取到独立的状态类中，状态模式能有效实现状态与行为的分离。

喜欢内容的话欢迎！！

喜欢内容的话欢迎！！

中介者模式是一种行为型设计模式，它通过引入一个中介者对象来简化对象之间的通信。中介者模式的主要目的是减少多个对象之间的直接交互，使得这些对象不需要显式地相互引用，从而降低系统的耦合度。中介者模式通过引入一个中介者对象来管理对象之间的复杂交互，降低了系统的耦合度，提高了系统的可维护性和扩展性。在实际应用中，选择合适的中介者实现方式非常重要，以避免中介者本身成为系统的瓶颈。欢迎！更多系列内容可以点击专栏目录祉猷并茂，顺遂无虞！若将文章用作它处，请一定注明出处，商用请私信联系我！