0%

门面模式(Facade Pattern):简化复杂系统的访问接口

门面模式(又称外观模式)是结构型设计模式的一种,核心思想是为多个复杂的子系统提供一个统一的高层接口,通过这个接口简化客户端与子系统的交互,屏蔽内部细节。这种模式就像 “前台服务员”,客户端无需直接与后台多个部门打交道,只需通过前台即可完成所有操作。

门面模式的核心结构

外观模式

门面模式的结构简单清晰,主要包含两个角色:

门面角色(Facade)

  • 定义一个统一的接口,负责协调多个子系统的交互。
  • 客户端通过调用门面角色的方法间接访问子系统,无需了解子系统的具体实现。

子系统角色(Subsystem)

  • 由多个相互关联或独立的类组成,实现具体的业务逻辑。
  • 子系统不知道门面角色的存在,仅关注自身功能的实现。

代码实现示例

以 “家庭影院系统” 为例,子系统包括投影仪、音响、播放器等,门面角色 “影院控制器” 提供一键播放功能,简化操作:

子系统角色(各类设备)

阅读全文 »

备忘录模式(Memento Pattern):对象状态的快照与恢复

备忘录模式是行为型设计模式的一种,核心思想是在不破坏对象封装性的前提下,捕获对象的内部状态并保存,以便后续将对象恢复到该状态。这种模式就像 “游戏存档”—— 玩家可在关键时刻保存进度,后续可随时加载存档回到之前的状态,核心功能是 “状态的保存与恢复”。

备忘录模式的核心结构

备忘录模式

备忘录模式通过三个核心角色实现状态的安全存储与恢复,分工明确且保障封装性:

原发器(Originator)

  • 需要被保存状态的对象,负责创建备忘录(记录当前状态)和从备忘录恢复状态。
  • 示例:GameRole(游戏角色,需保存生命值、魔法值等状态)。

备忘录(Memento)

  • 存储原发器状态的对象,通常由原发器创建,包含原发器的部分或全部内部状态。
  • 备忘录的访问权限严格控制:仅允许原发器读写其状态,其他对象无法修改(保障封装性)。
  • 示例:GameRoleMemento(存储游戏角色的生命值、魔法值)。

管理者(Caretaker)

  • 负责管理备忘录的对象,仅存储备忘录但不查看或修改其内容,相当于 “存档管理器”。
  • 示例:GameSaveManager(保存多个游戏存档,提供存档和读档接口)。

代码实现示例

以 “游戏角色状态存档” 为例,展示备忘录模式的实现:游戏角色可保存当前状态(生命值、魔法值),并在需要时恢复。

阅读全文 »

状态模式(State Pattern):基于状态的行为动态切换

状态模式是行为型设计模式的一种,核心思想是允许对象在内部状态改变时自动改变其行为,使对象看起来好像修改了它的类。这种模式将不同状态对应的行为封装到独立的状态类中,通过状态的切换实现行为的动态变化,本质是 “将状态转换逻辑与状态对应的行为分离,用类表示状态”。就像 “交通信号灯”—— 红灯、黄灯、绿灯对应不同的行为(禁止通行、准备停止、允许通行),灯的状态改变时,行为也随之改变。

状态模式的核心结构

状态模式

状态模式通过三个核心角色实现状态与行为的绑定及动态切换:

上下文(Context)

  • 维护当前状态并提供切换状态的接口,是状态模式的使用者。
  • 上下文本身不实现具体行为,而是将行为委托给当前状态对象。
  • 示例:TrafficLight(交通信号灯,持有当前灯状态的引用)。

状态接口(State)

  • 定义所有具体状态的公共接口,声明状态对应的行为方法(如handle())。
  • 示例:LightState(灯状态接口,声明show()方法表示灯的显示行为)。

具体状态(ConcreteState)

  • 实现状态接口,封装特定状态下的行为逻辑,并可在适当时候触发状态切换(通过修改上下文的当前状态)。
  • 示例:RedLight(红灯状态)、YellowLight(黄灯状态)、GreenLight(绿灯状态)。

代码实现示例

以 “交通信号灯” 为例,展示状态模式的实现:信号灯有红、黄、绿三种状态,每种状态对应不同的显示行为,且状态会按 “红→绿→黄→红” 的顺序切换。

阅读全文 »

观察者模式(Observer Pattern):对象间的联动通知机制

观察者模式是行为型设计模式的一种,核心思想是定义对象间的一对多依赖关系:当一个对象(目标)的状态发生改变时,所有依赖它的对象(观察者)会自动收到通知并更新。这种模式就像 “订阅 - 发布” 系统 —— 订阅者(观察者)关注发布者(目标),当发布者有新内容时,所有订阅者都会收到推送,核心是 “状态联动,自动更新”。

观察者模式的核心结构

观察者模式

观察者模式通过四个核心角色实现对象间的联动,分工明确且耦合度低:

目标接口 / 类(Subject)

  • 定义被观察对象的接口,提供注册、移除观察者及通知所有观察者的方法。
  • 示例:NewsPublisher(新闻发布者,定义addSubscriber()removeSubscriber()notifySubscribers())。

具体目标(ConcreteSubject)

  • 实现目标接口,维护自身状态,当状态改变时调用notify()方法通知所有观察者。
  • 示例:TechNewsPublisher(科技新闻发布者,状态为最新新闻内容)。

观察者接口(Observer)

  • 定义观察者的接口,声明接收通知并更新自身的方法(通常名为update())。
  • 示例:Subscriber(订阅者,定义update(String news)方法)。

具体观察者(ConcreteObserver)

  • 实现观察者接口,在收到通知时执行具体的更新逻辑,通常会保存对目标的引用以获取最新状态。
  • 示例:EmailSubscriber(邮件订阅者,收到新闻后发送邮件)、AppSubscriber(APP 订阅者,收到新闻后推送通知)。

代码实现示例

以 “新闻订阅系统” 为例,展示观察者模式的实现:新闻发布者(目标)发布新闻时,所有订阅者(观察者)会自动收到通知。

阅读全文 »

访问者模式(Visitor Pattern):数据与操作的分离艺术

访问者模式是行为型设计模式的一种,核心思想是封装作用于数据结构中各元素的操作,使这些操作可以独立于数据结构变化。它通过 “双分派” 机制,在不修改元素类的前提下,为元素添加新的操作,本质是 “预留访问通路,通过回调实现操作扩展”。

访问者模式的核心结构

访问者模式

访问者模式通过五个核心角色实现数据与操作的分离,分工明确且支持灵活扩展:

抽象元素(Element)

  • 定义数据结构中元素的抽象接口,声明一个accept(Visitor visitor)方法,用于接受访问者的访问(核心方法,实现双分派的关键)。
  • 示例:Shape(图形抽象类,声明accept(Visitor v))。

具体元素(ConcreteElement)

  • 实现抽象元素接口,重写accept方法,并在方法中调用访问者的对应visit方法(将自身作为参数传递)。
  • 示例:Circle(圆形)、Rectangle(矩形)。

抽象访问者(Visitor)

  • 定义对所有具体元素的访问接口,每个方法对应一种具体元素(方法名通常为visitConcreteElementX)。
  • 示例:ShapeVisitor(图形访问者接口,声明visitCircle(Circle c)visitRectangle(Rectangle r))。

具体访问者(ConcreteVisitor)

  • 实现抽象访问者接口,封装对具体元素的操作逻辑(如计算面积、绘制图形等)。
  • 示例:AreaCalculator(计算面积的访问者)、ShapeDrawer(绘制图形的访问者)。

5对象结构(ObjectStructure)

  • 管理元素的集合(如列表、树等),提供遍历元素的方法,并可触发访问者对所有元素的访问。
  • 示例:ShapeGroup(图形组,包含多个图形元素)。

核心机制:双分派(Double Dispatch)

访问者模式的关键是 “双分派” 机制,通过两次分发决定最终执行的操作:

阅读全文 »