23种设计模式

一、什么是设计模式                                                                                                  

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。简单说：

模式：在某些场景下，针对某类问题的某种通用的解决方案。

场景：项目所在的环境

问题：约束条件，项目目标等

解决方案：通用、可复用的设计，解决约束达到目标。

比如做生意开个工厂，怎么才能挣钱。设计模式就是前人挣钱的一些成功经验

创建型模式（关注点是快速复制）：

• 描述：这些模式主要关注于如何创建对象，它们将对象的创建与使用分离，使得代码更加灵活和可维护。想象一下，当你需要创建多种类型的对象，但又不想在代码中直接实例化它们时，创建型模式就派上了用场。

• 关注点：如何快速、有效地制作食物（即创建对象）。
• 情景：在快餐店，顾客下单后，后厨会按照顾客的点餐内容快速制作食物。

单例模式：本体和分身是一样的

• 单例模式确保一个类仅有一个实例，并提供一个全局访问点。可以通过静态字段和私有构造函数来实现。（new 都是同一个对象）
• 场景：假设我们有一个独特的厨房工具，例如一个特制的烤箱，它在整个制作过程中只需要一个实例。

• 应用：

• 单例模式确保整个制作过程中只有一个特制烤箱的实例。
• 无论多少次请求使用烤箱，都返回同一个烤箱实例，避免了资源的重复创建和浪费。

原型模式：本体和分身是不一样的

• 通过复制现有对象来创建新对象，而无需通过新的类实例化。

  场景：当需要制作大量相同或相似的食物时，例如制作多个相同的蛋糕。

  应用：

• 创建一个蛋糕的原型对象，该对象包含了制作蛋糕所需的所有信息和状态。
• 当需要制作一个新的蛋糕时，通过复制原型对象来快速生成一个新的蛋糕实例，而无需从头开始制作。

简单工厂方法模式（一维度工厂模式,一个厨师做多份）：

本质上简单工厂方法是不符合开闭原则的

工厂方法模式（二维度工厂模式，多个厨师，每个厨师专门做一项）：

• 定义一个用于创建对象的接口，让子类决定实例化哪一个类。   （后厨是一个“工厂”，负责生产（创建）各种食物（对象）。根据顾客的点餐内容（参数），后厨会制作相应的食物。）

场景：一个餐馆提供多种类型的食物，如披萨、汉堡和沙拉。每种食物的制作方法都不同，但都需要遵循一定的制作流程。

应用：

• 定义一个食物接口或抽象类，规定所有食物都需要实现的制作方法。
• 为每种食物类型创建一个具体的工厂类（如披萨工厂、汉堡工厂、沙拉工厂），每个工厂负责生产对应的食物实例。
• 客户端代码通过调用相应的工厂方法来获取食物实例，而无需关心具体的制作细节。
• 满足开闭原则，但不满足单一职责原则

抽象工厂模式（多维度工厂模式=工厂模式+工厂模式）：

• 提供一个接口，用于创建相关或依赖对象的家族，而无需明确指定具体类。

场景：一个大型的餐饮集团，提供多种类型的菜系，如中式菜、西式菜和日式菜。每种菜系都包含多种具体的食物，如中式菜包含炒饭、饺子等，西式菜包含披萨、汉堡等。

应用：

• 定义一个抽象工厂接口，该接口声明了创建不同菜系食物的方法。
• 为每种菜系创建一个具体的工厂类（如中式菜工厂、西式菜工厂），这些工厂实现了抽象工厂接口，并负责生产该菜系下的所有食物实例。
• 客户端代码通过调用相应菜系的工厂来获取食物实例的集合，从而能够灵活地切换不同的菜系和食物组合。

建造者模式（奶茶店，存在定制化需求）：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

场景：

假设你正在制作一个汉堡。一个汉堡由面包、生菜、肉饼、酱料等多个部分组成，每个部分都可以有不同的选择（比如面包可以是全麦的或白面的，肉饼可以是牛肉的或鸡肉的，酱料可以是番茄酱或芥末酱等）。

如果你不使用建造者模式，你可能需要创建一个汉堡类，并在其构造函数中传入所有的参数（面包类型、生菜、肉饼类型、酱料等）。但是，这样做有几个问题：

1. 构造函数可能会变得非常庞大和复杂，参数很多且可能相互依赖。
2. 如果你想要创建具有不同配置的汉堡，你需要为每种配置编写一个新的构造函数或方法，这会导致代码的可读性和可维护性降低。

应用：

1. 而使用建造者模式，你可以这样做：
2. 首先，定义一个汉堡类（Product），表示最终要构建的对象。
3. 然后，创建一个汉堡建造者接口（Builder），定义构建汉堡的各个步骤方法（如设置面包、添加生菜、添加肉饼、添加酱料等）。
4. 实现一个或多个具体的汉堡建造者类（ConcreteBuilder），每个类都实现了汉堡建造者接口，并控制汉堡的构建过程。这些类可以根据需要创建出具有不同配置的汉堡。
5. 创建一个汉堡指挥者类（Director），它负责指导汉堡的构建过程。指挥者类并不直接参与汉堡的构建，而是调用建造者类的方法来构建汉堡。

2.结构型模式（关注点是组装）：

结构型模式关注于类和对象的组合方式，它们描述如何将类或对象按某种布局组成更大的结构，以达到更好的代码结构和可重用性。结构型模式主要包括以下几种：

• 关注点：如何将不同的家具部件（对象）组合成一个完整的家具（系统）。
• 情景：你购买了一个书架的散件，需要将这些散件组装成一个完整的书架。

组合模式：定义部件，组装模型。零部件生成商(含有部分组装功能)

允许你将对象组合成树形结构来表示“部分-整体”的层次结构，使得客户对单个对象和复合对象的使用具有一致性。

• 定义：将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
• 家具部件例子：在家具设计中，你可以将家具视为一个组合对象，它由多个部件（如腿、扶手、抽屉等）组成。这些部件本身也可以是组合对象，由更小的部件组成。组合模式允许你以统一的方式处理这些部件和组合对象，例如计算它们的总价或遍历它们的结构。

代理模式（代理商）： 一般与组合模式使用，从零部件生成商进货，然后自己弄些加工

为其他对象提供一个代理以控制对这个对象的访问。但可能增加代码的复杂性。

代理模式常常用于在访问真实对象前后添加一些额外的处理逻辑，如权限验证、日志记录、事务管理等。

适配器模式： 一般与组合模式使用，从各零部件生成商进货，然后自己弄些适配

将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。

• 定义：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
• 家具部件例子：你有一个欧洲标准的电源插头（目标），但你的家具（客户）使用的是美国标准的插座。为了解决这个问题，你购买了一个适配器（电源适配器），它将欧洲标准的插头转换成美国标准的插座，使家具能够正常工作。

桥接模式：（就是把组合模式中的部件抽象一下）

目的：桥接模式将抽象部分与实现部分分离，使它们可以独立地变化。抽象部分和实现部分之间使用接口或抽象类进行连接。

应用场景：当需要在多个维度上变化一个对象时，但又不想用继承导致类爆炸时，可以使用桥接模式。

组合模式：（上游部件供应商）

在组合模式中，你可以将家具部件（如椅子、桌子等）视为叶节点，而完整的家具套餐（如美国家具套餐、中国家具套餐）则被视为组合节点。组合模式允许你将这些部件和家具组合成一个树形结构，以表示整体和部分的关系。

对于家具组装工厂来说，组合模式的好处在于，你可以轻松地添加、移除或替换部件，而无需对整个家具结构进行大的改动。例如，如果你想要生产一款新的欧洲，只需要将新的椅子与现有的桌子组合在一起即可。这种灵活性使得组合模式非常适合于需要经常变更产品配置的工厂。

桥接模式：（要把控每一步细零部件，多维组合）

桥接模式则更关注于将抽象部分与实现部分分离，使得它们可以独立地变化。在家具组装工厂的情境中，你可以将家具的抽象部分（如椅子的设计图或桌子的样式）与具体的实现部分（如用于制造家具的木材、五金件等）分离开来。

桥接模式的好处在于，当你需要修改家具的设计或更换制造材料时，只需要修改抽象部分或实现部分中的一部分，而无需对整个系统进行大的改动。例如，如果你想要生产一款具有不同样式或材质的椅子，只需要更换椅子的设计图或选择不同的木材即可，而无需改变椅子的制造流程。

总结：

从家具组装工厂的角度来看，组合模式更适合于构建灵活可变的产品结构，而桥接模式则更适合于将产品的设计和制造过程分离开来，以实现更高效的变更和维护。在实际应用中，你可以根据工厂的具体需求和产品的特性来选择使用哪种模式。

装饰器模式：（怎么快捷的添加装饰,AOP思想开放封闭原则）

动态地给一个对象添加一些额外的职责，就增加功能来说，装饰器模式相比生成子类更为灵活。

• 定义：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰器模式相比生成子类更为灵活。
• 家具部件例子：你有一个简单的椅子（原始对象），但你想要给它添加一些额外的功能，如扶手（装饰器）或垫子（另一个装饰器）。你可以将这些装饰器动态地添加到椅子上，而无需修改椅子的原始设计。

外观模式：（最少知识法则）

为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式隐藏了子系统的复杂性，使得客户端只需要与外观对象交互，而无需关心子系统的具体实现细节。

• 定义：为子系统中的一组接口提供一个统一的接口。外观模式定义了一个高层接口，这个接口使得子系统更加容易使用。
• 家具部件例子：想象一下你开了一个家具厂，你是否希望你的工人懂得桌子腿 桌面雕花 桌子组装等全部流程？如果你是老板肯定是不希望的，然后就工人就单干了 。外观模式其实就是只暴露简单的组装部分，让普通工人不用了解复杂的工艺

享元模式：（围棋）

运用共享技术来有效地支持大量细粒度的对象。

如果我们用面向对象的方式来模拟围棋游戏，可能会为每个棋子都创建一个对象。但是，由于棋子的颜色是有限的（只有两种），我们可以使用享元模式来减少对象的数量。

与原型模式区别：

• 享元模式的核心理念是：当系统中存在大量相似对象时，如果它们的内部状态可以共享，那么就可以通过复用这些内部状态来减少对象的数量，从而降低内存消耗并提高性能。

  以围棋中的黑白子为例，我们可以这样解释享元模式：

  围棋中的黑白子

  在围棋中，棋子有两种颜色：黑色和白色。这些棋子在棋盘上的位置是不断变化的，但是它们的颜色（即类型）是不变的。

  享元模式的解释

• 内部状态：在围棋中，棋子的颜色（黑色或白色）就是享元的内部状态。这部分状态是固定的，不会因为棋子的位置变化而改变。
• 外部状态：棋子的位置就是享元的外部状态。这部分状态是随着棋局的变化而变化的，由客户端（即下棋的人）来管理和维护。
• 我们可以创建一个享元工厂，用于管理两种颜色的棋子对象。当需要一个新的棋子时，工厂会检查是否已经存在相同颜色的棋子对象。如果存在，就返回已有的对象；如果不存在，就创建一个新的对象并保存起来。
• 在实际的游戏过程中，我们只需要记录每个棋子的位置（外部状态），而不需要为每个棋子都创建一个新的对象。这样可以大大减少对象的数量，提高程序的性能
• 目的：享元模式是为了减少对象数量，通过共享来节省内存和提高系统效率；而原型模式是为了快速创建大量相似对象，通过复制现有对象来避免重复的初始化过程。
• 实现方式：享元模式将对象的状态分为内蕴状态和外蕴状态，并通过享元工厂来管理对象的创建和共享；而原型模式则通过实现克隆方法来复制现有对象。
• 适用场景：享元模式适用于系统中存在大量相似对象，并且这些对象可以共享相同状态的情况；而原型模式适用于创建对象的成本较大，需要频繁创建和销毁对象的情况。
• 性能考虑：享元模式通过减少对象数量来提高性能；而原型模式则通过避免重复的初始化过程来提高性能。

3.行为型模式（对象之间的协作）：

行为型模式关注于对象之间的通信和协作方式，它们描述了在程序运行时对象之间如何进行交互、如何分配职责以及如何在对象之间传递消息。行为型模式主要包括以下几种：

• 关注点：团队成员（对象）之间如何协作完成任务。
• 情景：一个项目团队需要协作完成一个项目。

模板方法模式：

定义一个操作中的算法的框架，而将一些步骤延迟到子类中。

• 定义：定义了一个算法的骨架，并允许子类为一个或多个步骤提供实现。
• 团队成员协作类比：团队有一个固定的项目流程（算法骨架），但每个团队成员可以根据自己的专长（子类）来完成流程中的某个或多个任务。

生活中的例子可以有很多，但为了简单起见，我们可以考虑制作咖啡的过程。不同的咖啡可能有不同的步骤（如添加牛奶、糖浆等），但基本步骤（如研磨咖啡豆、加水、煮沸等）是相同的。

实现方案：美式咖啡继承咖啡，拿铁继承咖啡  其中 AddIngredients继承重写不同点，就是提供一个方法进行重写，重复的步骤不重写

策略模式：（最优策略）

定义了一系列的算法，并将每一个算法封装起来，使它们可以互相替换。

• 定义：定义了算法家族，分别封装起来，让它们之间可以相互替换。
• 团队成员协作类比：团队成员面临不同的任务时，可以根据任务的特点选择最适合的策略（算法）来完成。例如，面对市场推广任务，有的成员可能擅长线上推广，有的擅长线下活动。

生活中的一个例子可以是在餐厅点餐时选择不同的支付方式。餐厅支持多种支付方式，如现金、信用卡、移动支付等，每种支付方式都是一种策略。餐厅的收银系统可以根据客户的选择来应用不同的支付策略。（其实就是把不同的支付方式封装好，统一一个类调用）

namespace 策略模式
{
    // 支付策略接口  
    public interface IPaymentStrategy
    {
        void Pay(decimal amount);
    }

    // 现金支付策略  
    public class CashPaymentStrategy : IPaymentStrategy
    {
        public void Pay(decimal amount)
        {
            Console.WriteLine($"支付 {amount}现金.");
        }
    }

    // 信用卡支付策略  
    public class CreditCardPaymentStrategy : IPaymentStrategy
    {
        public void Pay(decimal amount)
        {
            Console.WriteLine($"支付 {amount}  通过信用卡支付.");
            // 这里可以添加信用卡支付的具体逻辑  
        }
    }

    // 移动支付策略  
    public class MobilePaymentStrategy : IPaymentStrategy
    {
        public void Pay(decimal amount)
        {
            Console.WriteLine($"支付 {amount} 通过移动支付.");
            // 这里可以添加移动支付的具体逻辑  
        }
    }
}

    // 上下文类（收银系统）  
    public class CheckoutContext
    {
        private IPaymentStrategy _paymentStrategy;

        public CheckoutContext(IPaymentStrategy paymentStrategy)
        {
            _paymentStrategy = paymentStrategy;
        }

        public void ProcessPayment(decimal amount)
        {
            _paymentStrategy.Pay(amount);
        }

        // 可以添加一个方法来更改支付策略  
        public void SetPaymentStrategy(IPaymentStrategy paymentStrategy)
        {
            _paymentStrategy = paymentStrategy;
        }
    }

// 创建一个收银系统实例，并设置支付策略为现金支付  
using 策略模式;
// 现金支付
CheckoutContext checkout = new CheckoutContext(new CashPaymentStrategy());
checkout.ProcessPayment(100.0m);  

// 更改支付策略为信用卡支付  
checkout.SetPaymentStrategy(new CreditCardPaymentStrategy());
checkout.ProcessPayment(150.0m); 

// 更改支付策略为移动支付  
checkout.SetPaymentStrategy(new MobilePaymentStrategy());
checkout.ProcessPayment(50.0m); 

 

命令模式（一个命令的集合 。一般用来做日志记录，撤销等操作）：

将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

• 定义：将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。
• 团队成员协作类比：团队成员之间的任务请求被封装成命令对象，这些对象可以被传递、记录或撤销。例如，项目经理可以将一个任务请求（命令）分配给某个团队成员，并跟踪其进度。

在餐厅里，服务员会接收顾客的点餐请求，并将这些请求传递给厨房。服务员并不直接告诉厨师做什么菜，而是传递一个“命令”给厨房。这样，服务员就可以记录所有点过的菜，改变点菜的顺序，甚至在某些情况下撤销一个已经下的订单。

也有很多例子会举例遥控器，遥控器 换台、调声音、调色差这些命令也是命令集合。所以命令模式也经常用于 做日志记录，撤销等操作

实现方法

职责链模式（公司审批）：

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。

• 定义：为请求创建一个接收该请求对象的链，链条中每个元素都是一个对象。
• 团队成员协作类比：团队成员之间形成一个处理请求的链，每个成员负责处理自己职责范围内的请求，如果无法处理则传递给链中的下一个成员。

假设一个员工想要请假，根据公司的规定，不同的请假天数需要不同的审批级别。例如，小于等于3天的假期可以由部门经理审批，超过3天但小于等于7天的假期需要由部门经理和人力资源部门审批，超过7天的假期则需要更高层级的领导审批。

状态模式： 不同的状态，给你不同的反馈

允许一个对象在其内部状态改变时改变它的行为。

• 定义：允许一个对象在其内部状态改变时改变它的行为。
• 团队成员协作类比：团队成员根据项目的不同阶段（状态）调整自己的工作方式和协作策略。

比如一个咖啡机的状态变化。咖啡机通常有多种状态，比如“空闲”、“加热中”、“准备制作咖啡”、“制作咖啡中”等。每种状态下，咖啡机可以执行的操作是不同的。

如：

咖啡机 是关闭状态的， 点击 制作咖啡 、打开咖啡机、倒出咖啡 、添加水  按钮的时候，应该给你什么反馈

咖啡机 是制作状态的， 点击 关闭咖啡 、打开咖啡机、倒出咖啡 、添加水  按钮的时候，应该给你什么反馈

.....

假如你在制作咖啡状态，点击加水=提示不能加

假如你在开机状态，点击加水=能加

把所有状态列举反馈出来

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace 状态描述
{

    


    // 咖啡机状态的抽象接口  
    public interface ICoffeeMachineState
    {


        void PowerOn();// 打开咖啡机  
        void PowerOff();// 关闭咖啡机  
        void BrewCoffee();// 开始制作咖啡  
        void DispenseCoffee(); // 倒出咖啡  
        void AddWater();//  添加水  
    }

    // 空闲状态  
    public class IdleState : ICoffeeMachineState
    {
        private readonly CoffeeMachine _coffeeMachine;

        public IdleState(CoffeeMachine coffeeMachine)
        {
            _coffeeMachine = coffeeMachine;
        }

        public void PowerOn()
        {
            Console.WriteLine("咖啡机正在加热...");
            _coffeeMachine.SetState(new HeatingState(_coffeeMachine));
        }

        public void PowerOff()
        {
            Console.WriteLine("咖啡机已经是关闭状态。");
        }

        public void BrewCoffee()
        {
            Console.WriteLine("请先打开咖啡机。");
        }

        public void DispenseCoffee()
        {
            Console.WriteLine("没有咖啡可以倒出。");
        }

        public void AddWater()
        {
            Console.WriteLine("添加水到咖啡机。");
        }
    }

    // 加热状态  
    public class HeatingState : ICoffeeMachineState
    {
        private readonly CoffeeMachine _coffeeMachine;

        public HeatingState(CoffeeMachine coffeeMachine)
        {
            _coffeeMachine = coffeeMachine;
        }

        public void PowerOn()
        {
            Console.WriteLine("咖啡机已经是打开状态。");
        }

        public void PowerOff()
        {
            Console.WriteLine("咖啡机正在关闭...");
            _coffeeMachine.SetState(new IdleState(_coffeeMachine));
        }

        public void BrewCoffee()
        {
            Console.WriteLine("开始制作咖啡...");
            _coffeeMachine.SetState(new BrewingCoffeeState(_coffeeMachine));
        }

        public void DispenseCoffee()
        {
            Console.WriteLine("倒出咖啡...");
        }

        public void AddWater()
        {
            Console.WriteLine("添加水到咖啡机。");
        }

        // 其他方法与IdleState相同或不需要在加热状态下执行  

        // ...  
    }

    // 制作咖啡状态  
    public class BrewingCoffeeState : ICoffeeMachineState
    {
        private readonly CoffeeMachine _coffeeMachine;

        public BrewingCoffeeState(CoffeeMachine coffeeMachine)
        {
            _coffeeMachine = coffeeMachine;
        }

        public void AddWater()
        {
            throw new NotImplementedException();
        }

        // ... 其他方法与前面状态类似  

        public void BrewCoffee()
        {
            Console.WriteLine("咖啡机已经在制作咖啡了。");
        }

        public void DispenseCoffee()
        {
            Console.WriteLine("咖啡制作完成，正在倒出...");
            _coffeeMachine.SetState(new IdleState(_coffeeMachine)); // 假设倒出咖啡后回到空闲状态  
        }

        public void PowerOff()
        {
            Console.WriteLine("关闭...");
        }

        public void PowerOn()
        {
            Console.WriteLine("咖啡机已经是打开状态。");
        }

        // ...  
    }



}

执行

        CoffeeMachine coffeeMachine = new CoffeeMachine();

        //设置当前状态为加热
        ICoffeeMachineState _currentState = new HeatingState(coffeeMachine); 
        coffeeMachine.SetState(_currentState);
        
        // 模拟用户操作  
        coffeeMachine.PowerOn(); // 打开咖啡机  
        coffeeMachine.AddWater(); // 添加水  
        coffeeMachine.BrewCoffee(); // 开始制作咖啡  
        coffeeMachine.DispenseCoffee(); // 倒出咖啡  
        coffeeMachine.PowerOff(); // 关闭咖啡机  

观察者模式：（订阅发布）

定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。当主题对象状态发生改变时，它的所有依赖者（观察者）都会收到通知并自动更新。

• 定义：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
• 团队成员协作类比：某个团队成员（被观察者）的进度或状态发生变化时，其他依赖于此成员的团队成员（观察者）都会得到通知并作出相应调整。

假设你订阅了一个天气预报服务。这个服务是主题（Observable），而你是一个观察者（Observer）。当天气发生变化时，天气预报服务会通知你。

中介者模式：

用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

• 定义：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
• 团队成员协作类比：团队成员之间通过中介者（如项目经理）进行沟通和协作，而不需要直接相互沟通，从而减少了耦合性。

迭代器模式：

• 定义：提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。
• 团队成员协作类比：团队成员之间可能需要按照一定的顺序（如优先级、专长等）来协作完成任务，迭代器模式可以帮助他们确定协作的顺序。

访问者模式：

• 定义：将数据操作与数据结构分离的设计模式，作为类的行为分离出去。
• 团队成员协作类比：在项目中，不同的团队成员（访问者）可能需要对同一组数据（数据结构）进行不同的操作（行为），访问者模式可以帮助他们在不改变数据结构的情况下添加新的操作。

这些模式在软件设计和开发中起着至关重要的作用，它们可以帮助我们更好地组织代码、提高代码的可读性和可维护性，以及增强系统的可扩展性和可重用性。

在面向对象编程（OOP）中，接口（Interface）是一种重要的概念，但它并不是每个对象都必须直接“拥有”的。然而，理解接口在面向对象设计中的用途和重要性是关键。

首先，接口定义了一组方法的规范，但不包含这些方法的实现。它允许不同的类去实现这个接口，并确保它们提供相同的方法集。接口的主要目的是实现多态性（Polymorphism），这是面向对象编程的三大特性之一（封装、继承、多态）。

以下是为什么接口在面向对象编程中重要的几个原因：

1. 解耦：接口允许我们将对象的实现与其使用方式分离。通过定义一个接口，我们可以编写不依赖于特定实现的代码，从而增加代码的灵活性和可维护性。

2. 多态性：通过接口，我们可以实现多态性，即不同的对象可以使用相同的方式来处理。这意味着我们可以编写与接口交互的代码，而不需要关心实际实现该接口的对象的类型。

3. 扩展性：当需要添加新功能或更改现有功能时，使用接口可以使更改更加容易。因为接口定义了方法的规范，所以我们可以添加新的实现类，而不需要修改使用接口的代码。

4. 模块化：接口有助于将代码划分为更小的、更易于管理的模块。每个模块可以定义自己的接口，并通过这些接口与其他模块进行交互。

5. 易于测试：使用接口可以使代码更易于测试。我们可以为接口编写模拟（Mock）实现，以便在测试过程中模拟复杂的行为或外部依赖项。

虽然每个对象本身并不直接“拥有”接口，但对象所属的类可以实现一个或多个接口。当类实现接口时，它承诺提供接口中定义的所有方法。这样，通过该类的对象，我们可以调用这些方法，而无需关心该对象的实际类型。