weixin_45969711的博客

前端控制器模式（Front Controller Pattern）是一种软件设计模式，它将应用程序的请求处理逻辑集中在一个单一的组件中，这个组件被称为前端控制器。前端控制器负责接收所有来自客户端的请求，并根据请求的类型和内容，将其分发给相应的处理程序进行处理。

组合实体模式是一种将多个相关对象组合成一个整体实体的设计模式，通过这种方式，将复杂的对象关系进行封装和管理，使得客户端可以像操作单个对象一样操作这些组合对象。在实际应用中，组合实体模式通常用于处理包含多个相关数据和操作的复杂实体。例如，在一个电商系统中，订单实体可能包含订单基本信息、客户信息、商品列表、支付信息等多个子实体，这些子实体之间存在紧密的关联和依赖。使用组合实体模式，就可以将这些子实体组合成一个订单实体，客户端只需要与订单实体进行交互，而无需关心其内部子实体的具体实现和复杂关系。

业务代表模式主要用于在表示层（如用户界面）和业务逻辑层之间搭建起一座桥梁，通过一个名为 “业务代表” 的中间层对象，封装对业务服务的访问逻辑。它将业务服务的复杂性和底层实现细节隐藏起来，让表示层能够以一种简单、统一的方式调用业务服务。以一个在线教育平台为例，用户在前端界面上进行课程查询、报名等操作，这些操作背后涉及到复杂的数据库查询、用户权限验证等业务逻辑。

MVC 模式将应用程序分为三个主要组件：模型（Model）、视图（View）和控制器（Controller）。其核心目的是实现关注点分离，把业务逻辑、用户界面和输入处理相互独立开来，使得代码库更易于管理和维护。例如，在一个电商应用中，商品信息、订单数据等属于模型部分；商品展示页面、购物车页面等属于视图部分；而处理用户的添加商品、删除商品、结算等操作的逻辑则属于控制器部分。通过这种分离，每个部分都能专注于自己的职责，当业务需求发生变化时，只需修改对应的部分，而不会影响到其他部分。

访问者模式表示一个作用于某对象结构中的各元素的操作，它使我们可以在不改变各元素类的前提下定义作用于这些元素的新操作。简单来说，访问者模式将数据结构和作用于结构上的操作解耦，使得操作集合可以相对自由地演化。例如，在一个文件系统中，文件和文件夹构成了对象结构，我们可以定义一个访问者来统计文件的数量、计算文件的总大小等操作，而不需要在文件和文件夹类中添加这些操作方法。

模板模式定义了一个算法的骨架，将一些步骤延迟到子类中实现。具体来说，模板模式通过在抽象类中定义一个模板方法，该方法包含了算法的主要步骤和执行顺序，而将其中某些具体步骤的实现留给子类。子类可以根据自身需求，实现这些抽象步骤，从而定制出符合特定业务逻辑的算法。例如，在一个图形绘制系统中，绘制图形的基本流程（如初始化画笔、设置颜色、绘制图形、清理资源等）可以定义在抽象类的模板方法中，而具体的图形绘制步骤（如绘制圆形、矩形、三角形等）则由不同的子类来实现。

空对象模式是用一个空对象来取代对 NULL 对象的检查。空对象是一个实现了抽象状态相关接口的对象，它虽然不包含任何实际的业务逻辑，但会覆盖抽象状态对象中的所有方法，只不过方法体为空。这意味着，当客户端调用空对象的方法时，不会抛出 NullPointerException，而是执行空操作，从而避免了因对象为 null 而引发的异常。

状态模式允许一个对象在其内部状态改变时改变它的行为，这个对象看起来像是改变了其类。简单来说，状态模式将对象的状态和行为封装在不同的状态类中，当对象的状态发生变化时，它的行为也会相应地改变。例如，在一个自动售货机系统中，售货机可能处于空闲、投币、出货、找零等不同状态，每个状态下售货机的行为是不同的。当处于空闲状态时，售货机等待用户投币；当处于投币状态时，售货机可以接收用户的选择并判断是否足够支付；当处于出货状态时，售货机执行出货操作；当处于找零状态时，售货机进行找零操作。

观察者模式定义了对象之间的一种一对多依赖关系，当一个对象（被观察者）的状态发生改变时，所有依赖它的对象（观察者）都会得到通知并自动更新。简单来说，观察者模式就像是一个消息发布与订阅系统，被观察者充当消息发布者，而观察者则是订阅者，当被观察者有新消息时，会自动推送给所有订阅的观察者。例如，在一个社交媒体平台上，用户发布一条动态，关注该用户的其他用户都会收到通知，这就是观察者模式的典型应用。

备忘录模式允许在不破坏对象封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便在需要时能够将对象恢复到之前保存的状态。简单来说，备忘录模式就像是给对象拍了一张 “快照”，记录下对象在某个特定时刻的状态，之后可以随时使用这张 “快照” 将对象恢复到那个时刻的状态。例如，在一个绘图软件中，用户绘制了一个图形，在进行下一步操作之前，系统可以创建一个备忘录，记录下当前图形的状态（如形状、颜色、位置等）。如果用户对后续操作不满意，就可以使用这个备忘录将图形恢复到之前的状态。

中介者模式定义了一个中介对象来封装一系列对象之间的交互，使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。简单来说，中介者模式就是在多个对象之间引入一个中介者，让对象之间的通信和协调都通过中介者来完成，而不是直接相互通信。这样做的好处是，当某个对象的行为发生变化时，只需要修改中介者的逻辑，而不需要修改其他对象的代码，提高了系统的可维护性和可扩展性。

迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。简单来说，迭代器模式就是将集合的遍历功能从集合类中分离出来，让一个迭代器对象来负责遍历集合，这样做的好处是，客户端在遍历集合时，不需要了解集合的内部结构，只需要通过迭代器提供的接口进行操作即可。例如，在一个电商系统中，商品列表是一个集合，我们可以使用迭代器来遍历商品列表，查看每个商品的信息，而不需要关心商品列表是如何存储和组织的。

命令模式将一个请求封装成一个对象，从而使我们可以用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。简单来说，命令模式把请求本身作为一个对象，这个对象可以像其他对象一样被存储、传递和调用，实现了请求发送者和接收者之间的解耦。例如，在一个游戏中，玩家的操作（如移动、攻击、跳跃等）可以被封装成命令对象，玩家作为请求发送者，游戏角色作为接收者，通过命令对象来实现玩家操作与游戏角色动作的解耦。

责任链模式为请求创建了一条由处理者对象组成的链，请求在这条链上传递，直到链上的某个处理者决定处理该请求。请求的发送者不需要知道链上的哪个对象最终处理了请求，这就将请求的发送者和接收者解耦，使得系统可以在不影响客户端的情况下，动态地重新组织和分配责任。例如，在一个请假审批系统中，员工提交请假申请，这个请求可能会依次经过组长、部门经理、总经理等多个审批者，最终由某个审批者决定是否批准请假，而员工只需要提交申请，不需要知道具体是哪个审批者进行了审批。

享元模式运用共享技术有效地支持大量细粒度对象的复用，旨在尽可能减少内存使用量，将那些相似的对象的共有部分抽取出来并共享，以此降低系统内存占用。例如，在一个文本处理系统中，如果每个字符都创建一个独立的对象，包含字体、字号、颜色等属性，那么当处理一篇较长的文档时，会产生大量的对象，消耗大量内存。而运用享元模式，对于相同字体、字号和颜色的字符，只创建一个共享对象，字符的位置等个性化属性则作为外部状态单独处理，这样就能大大减少对象的数量，降低内存消耗。

解释器模式是指给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。简单来说，就是把语言中的每个符号定义成一个对象类，从而把每个程序转换成一个具体的对象树。通过这种方式，我们可以将复杂的语法解析工作拆分为多个小类，避免创建大而全的解析类，提高代码的可维护性和可扩展性。

策略模式在 GoF 的《设计模式》一书中的定义为：定义一组算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化。简单来说，策略模式允许我们在运行时根据不同的情况选择不同的算法或行为，就如同在一场战斗中，战士可以根据敌人的特点和战场形势选择不同的武器和战术。

代理模式，简单来说，就是为其他对象提供一种代理以控制对这个对象的访问。在某些场景下，一个对象可能由于各种原因（如对象创建开销大、对象位于远程服务器等），不适合或者不能直接被客户端引用，而代理对象则可以在客户端和目标对象之间充当一个中介的角色，客户端通过代理对象来间接访问目标对象。这就好比我们在生活中通过房产中介来寻找合适的房子，房产中介就是代理对象，它帮助我们与房东（目标对象）进行沟通和协调，控制我们对房东的访问，同时也为我们提供了一些额外的服务，如筛选房源、安排看房等。

外观模式为子系统中的一组接口提供一个统一的高层接口，使得子系统更加容易被使用。它就像是一个 “大管家”，将系统内部复杂的操作和细节封装起来，对外只提供一个简单、统一的接口，让客户端无需了解系统内部的具体实现，就能轻松地与系统进行交互。

装饰器模式允许在不改变原类文件和不使用继承的情况下，动态地扩展一个对象的功能。它通过创建一个包装对象（即装饰器）来包裹真实的对象，这个包装对象和真实对象具有相同的接口，使得客户端在使用时无需区分到底是操作原始对象还是被装饰后的对象。装饰器在转发客户端请求给真实对象的前后，可以添加一些额外的功能，从而在运行时为对象增添新的行为。

组合模式，简单来说，就是将对象组合成树形结构，以此来表示 “部分 - 整体” 的层次关系。它最大的特点是让用户在使用单个对象和组合对象时，能够采用一致的方式。这就好比在一个文件系统中，文件和文件夹（目录）都可以被看作是一种节点。文件夹可以包含文件和其他子文件夹，而文件则是最底层的节点，没有子节点。用户在操作文件系统时，无论是打开一个文件，还是打开一个包含多个文件和子文件夹的文件夹，所使用的操作方式（如点击打开）是一致的，无需关心操作的到底是单个文件还是一个复杂的文件夹结构。

适配器模式的定义是：将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。其核心原理在于通过引入一个中间层 —— 适配器，来协调目标接口与现有接口之间的差异。适配器就像是一个翻译官，它理解两种不同的 “语言”（接口），并在两者之间进行转换，让原本无法沟通的双方能够顺利交流。例如，在一个音乐播放系统中，现有的音频播放器只能播放 MP3 格式的文件，但系统需求是能够播放多种格式的音频文件，如 VLC、MP4 等。

原型模式的定义是：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。它允许一个对象再创建另外一个可定制的对象，而无需知道如何创建的细节。其核心原理基于一个原型对象，该对象充当新对象的模板。通过克隆这个原型对象，能够得到一个新的对象，新对象的创建过程由原型对象完成，从而避开了具体的实例化细节。例如，在一个图形绘制系统中，需要创建多个相似的图形对象，如圆形、矩形等。如果每次都通过实例化类来创建，不仅繁琐，而且可能涉及复杂的初始化过程。

建造者模式的核心定义是：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。简单来说，就是把创建复杂对象的步骤封装起来，让客户端无需了解对象内部的具体构建细节，只需关注构建的结果。例如，在建造房屋时，建造者模式就如同专业的建筑团队，他们熟知房屋建造的每一个步骤，从打地基、砌墙、安装门窗到内部装修，而我们作为客户，只需要告诉他们我们想要的房屋类型（如别墅、公寓等），就可以坐等房屋建成，无需亲自参与每一个繁琐的建造环节。

抽象工厂模式的核心定义是：为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类。想象一下，你正在开发一个跨平台的图形界面应用程序，需要创建不同操作系统（如 Windows、MacOS、Linux）下的按钮、文本框等组件。使用抽象工厂模式，你可以定义一个抽象工厂接口，不同操作系统的具体工厂类实现这个接口，负责创建对应操作系统下的组件。这样，客户端只需要与抽象工厂接口交互，而无需关心具体的组件创建过程，极大地提高了代码的灵活性和可维护性。

工厂模式的核心是提供一个创建对象的方式，将对象的创建和使用分离开来。它允许调用者在不了解对象具体创建细节的情况下，获取所需的对象实例。用生活中的例子来类比，就像我们去汽车 4S 店买车，我们只需要告诉销售人员我们想要的车型，而不需要关心汽车是如何在工厂中生产制造的。在软件开发中，这意味着我们可以将复杂的对象创建逻辑封装在工厂类中，调用者只需与工厂类交互，就能轻松获取所需对象，从而降低了代码的耦合度，提高了系统的灵活性和可维护性。