CAUC_lin的博客

​ 工厂方法模式是一种经典的设计模式，它遵循面向对象的设计原则，特别是“开闭原则”，通过定义一个用于创建对象的接口，将对象的实例化过程推迟到子类中实现。这种模式与抽象工厂模式类似，但更加专注于对单一接口下产品类型的创建。二、适用场景复杂对象的创建需要大量重复代码时。对象创建依赖于外部资源或信息。需要统一管理对象生命周期，如会话、资源池对象等。需要隐藏对象的具体类型，提高代码的抽象层次。

Iterator（迭代器角色）：定义访问和遍历元素的接口，通常包含hasNext()next()等方法。ConcreteIterator（具体迭代器角色）：实现Iterator接口，负责跟踪当前遍历位置，并通过调用集合的相关方法来获取下一个元素。Aggregate（聚合角色）：定义创建迭代器对象的接口，通常是方法。以遍历集合为例，我们来具体实现迭代器模式：T next();定义具体迭代器类（ConcreteIterator）：创建一个名为的类，实现Iterator接口。if(!

​ 抽象工厂模式的成功运用关键在于能否找到正确的抽象层次。在实践中，开发者应首先识别出具有高度可复用性的抽象产品，然后再构建相应的具体工厂和产品。尽管在日常业务代码开发中较少直接应用抽象工厂模式，但它在许多优秀的开源框架中扮演了重要角色，体现了设计模式在软件架构层面的重要性。在选择设计模式时，应充分考虑项目需求和长期维护性，合理权衡是否采用抽象工厂模式。若仅需封装单个对象的创建过程，工厂方法模式可能更为合适。

Mediator（中介者角色）：定义一个接口，用于与各个Colleague对象进行通信，集中处理Colleague对象之间的交互。ConcreteMediator（具体中介者角色）：实现Mediator接口，它知道并维护各个Colleague对象，并负责协调它们之间的交互关系。Colleague（同事角色）：每一个Colleague都知道中介者，并通过中介者与其他Colleague对象进行通信，而不是直接与其他Colleague通信。

Strategy（策略接口/抽象类）：声明了一系列方法，用于定义所有支持的算法的公共接口。ConcreteStrategy（具体策略类）：实现了Strategy接口，提供了具体的算法实现。Context（上下文角色）：持有一个Strategy对象引用，用以调用其方法来执行相关算法，并在必要时能够更改所使用的策略。以电商平台的折扣策略为例，来具体实现策略模式：定义策略接口（Strategy）：创建一个名为的接口，其中包含一个计算折扣的方法。

AbstractClass（抽象类角色）：定义了一个或多个操作的模板方法，这些方法通常包含了一系列已定义好的步骤，同时也可以定义一些抽象方法供子类实现。ConcreteClass（具体类角色）：是AbstractClass的子类，实现了在抽象类中声明的抽象方法，从而完成算法中可变部分的定制。​ 模板方法模式通过在抽象类中定义一个算法骨架，并将可变步骤交由子类实现，有效地实现了算法结构的复用以及灵活扩展。

Facade（门面角色）：为子系统提供一个简化的高层接口，它包含了对各个子系统对象的引用，并负责协调它们之间的交互。Subsystem（子系统角色）：实现了子系统的具体功能，通常由多个类组成，各司其职，完成特定任务。​ 门面模式通过为复杂的子系统提供一个更高层的接口，简化了外部用户的使用方式，增强了系统的可维护性和扩展性。在实际应用中，合理运用门面模式能够有效解决复杂系统接口难用的问题，提升代码的复用性和用户体验。然而，在设计时应避免过度抽象，确保模式的应用符合实际需求和场景特点。

Abstraction（抽象化角色）：定义抽象接口，维持一个指向Implementor对象的引用。RefinedAbstraction（具体抽象化角色）：是Abstraction接口的一个实现，负责调用Implementor对象的方法并提供额外的功能。Implementor（实现化角色）：定义实现化角色的接口，供Abstraction角色调用。ConcreteImplementor（具体实现化角色）：实现了Implementor接口，提供了具体的实现。

Handler（抽象处理者）：定义了处理请求的接口，同时持有对下一个处理者的引用，以便于传递请求。ConcreteHandler（具体处理者）：继承自抽象处理者，实现了处理请求的方法，根据请求的具体内容判断自己是否可以处理该请求，如果可以则处理并返回；如果不可以，则将请求转发给下一个处理者。责任链模式通过分散请求处理的责任，赋予系统高度的灵活性和可扩展性，有效解决了多个对象可能需要处理同一请求的问题。

​ 创建者模式通过将构建过程与表示分离，使得客户端只需关注构建过程本身而不必关心具体产品的内部构造细节。这不仅提高了系统的灵活性和可扩展性，也使代码更加清晰易读，降低了模块间的耦合度。然而，过度使用创建者模式可能导致类数量增多，应合理评估是否真正需要创建者模式来处理对象的创建过程。

装饰者模式是一种结构型设计模式，允许在运行时给对象动态地增加新的职责或功能，而无需修改原有类。通过组合而非继承的方式，在不改变对象接口的前提下，增强对象的功能。此模式在实际应用中广泛应用于图形用户界面（GUI）组件、日志记录、权限控制等场景。装饰者模式包含以下核心组成部分：一个简单的咖啡售卖系统，其中存在基础咖啡以及各种调料作为装饰。创建基础咖啡类在这个部分，定义了一个抽象的Coffee类，它是所有咖啡的基础接口。然后创建了一个具体实现——Americano（美式咖啡），它具有描述和价格属性。创建装饰器抽

状态模式是一种行为设计模式，用于处理一个对象在其内部状态改变时，其行为也随之发生相应变化的情况。例如，在ATM机中，用户操作（取款、存款、查询等）会引发系统状态的变化和对应的操作；游戏角色根据所处状态（行走、奔跑、战斗）执行不同的动作。状态模式包含四个核心组成部分：模拟了一个简单的电商订单系统，这个系统通过状态模式来处理订单从创建到完成或取消的整个生命周期中的不同状态和操作。抽象状态角色（OrderState）：定义了所有具体状态类需要实现的方法接口，包括、、和等。具体状态角色：：代表订单刚创建的状态

适配器模式在软件设计中扮演着桥梁角色，解决不同接口之间的兼容问题。该模式通过创建一个适配器类，将原本不兼容的接口转换为预期的目标接口，使得原本无法协同工作的组件得以和谐共存。在现代软件开发中，适配器模式广泛应用于遗留系统升级、跨平台API调用、第三方库整合等场景。系统集成与扩展性：当需要将新的组件或服务融入现有系统时，如果新旧组件接口不匹配，适配器模式能提供一个中间层，无需修改原有代码即可实现对接。复用已有功能：对于一些已经存在的成熟库或框架，适配器模式可以将其接口转换为我们所需的形式，以充分利用其内部的功

观察者模式的核心是建立了一种一对多的依赖关系，使得当一个对象（被观察者）状态变化时，所有依赖它的对象（观察者）都能得到自动通知和更新。

代理模式的原始定义是：让你能够提供对象的替代品或其占位符。代理控制着对于原对象的访问，并允许将请求提交给对象前后进行一些处理。从这个定义中我们能看出，代理模式是作为对象之间的一种中间结构来使用的，通过构建一个代理对象来对原始的功能进行委托处理，其中有一个很重要的功能就是控制对象的访问。拿现实中的例子来说，假设你有一套房子要卖，可你却正好在外地出差，你不能亲自处理带人看房、过户等购房手续，这时你就可以找一个房产中介来作为你的代理人，委托他来帮你带人看房、处理过户手续。这就是现实中经典的代理模式的例子。