欢迎来到 W10N 的博客

AI Agent AI Agent（人工智能代理）是一个能够感知环境、自主决策并采取行动以完成目标的软件系统。 与普通程序不同，AI Agent 的核心特征是自主性：它不只是被动地响应单次输入，而是能够： 制定多步骤计划 调用外部工具（搜索、代码执行、API 调用等） 根据执行结果动态调整策略 持续循环直到目标完成 AI Agent 的定义 从学术角度，Agent 的经典定义来自 Russell & Norvig（《人工智能：一种现代方法》）： Agent 是任何能够通过传感器感知环境、并通过执行器对环境采取行动的事物。 在 LLM 时代，AI Agent 的定义更具体： AI Agent 是以大语言模型为核心推理引擎，能够自主规划任务、调用工具、与外部系统交互，并通过反馈循环完成复杂目标的自治系统。 Agent 的四个核心要素 要素 说明 感知（Perception） 接收输入：多模态用户指令、工具返回结果、系统状态、历史记忆 规划（Planning） 将目标分解为可执行的子任务序列 行动（Action） 调用工具、执行代码、调用 API、操作文件等 记忆（Memory） 短期记忆（上下文窗口）+ 长期记忆（向量数据库等） 感知的来源 感知不只是用户输入那一句话，Agent 每次推理前收到的完整上下文都属于"感知"： 来源 说明 多模态输入 用户的文本指令（最常见）、图片、音频、视频等 工具返回结果 搜索结果、API 响应、代码执行输出、数据库查询结果 系统状态 文件内容、环境变量、当前任务进度 历史记忆 短期记忆（上下文窗口中的对话历史）+ 长期记忆（从向量数据库检索） 这四类来源最终都会被拼装进 LLM 的上下文窗口，LLM 基于这个完整上下文做出下一步决策。因此，感知本质上是构建 LLM 输入上下文的过程。 上下文窗口：感知的硬性约束 能放入上下文的信息量取决于模型的上下文窗口大小（以 token 计）： 模型 上下文窗口 GPT-4o 128K tokens Claude 3.5 Sonnet 200K tokens Gemini 1.5 Pro 1M tokens 超出窗口的内容会被截断，因此 Agent 需要主动管理上下文。常见策略如下（各框架实现不一，没有统一标准）： ...

微服务 微服务是一种分布式系统解决方案。 微服务 (Microservices) 就是一些协同工作小而自治的服务。 2014年,Martin Fowler 与 James Lewis 共同提出了微服务的概念,定义了微服务是由以单一应用程序构成的小服务,自己拥有自己的进程与轻量化处理,服务依业务功能设计,以全自动的方式部署,与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力,服务可以用不同的编程语言与数据库等组件实现 。 微服务与SOA 「面向服务的体系结构」 SOA (Service-Oriented Architecture) 听起来和微服务很像,但 SOA 早期均使用了总线模式,这种总线模式是与某种技术栈强绑定的,比如: J2EE。这导致很多企业的遗留系统很难对接,切换时间太长,成本太高,新系统稳定性的收敛也需要一些时间,最终 SOA 看起来很美,但却成为了企业级奢侈品,中小公司都望而生畏。 此外,实施SOA时会遇到很多问题,比如通信协议 (例如SOAP)的选择、第三方中间件如何选择、服务粒度如何确定等,目前也存在一些关于如何划分系统的指导性原则,但其中有很多都是错误的。SOA并没有告诉你如何划分单体应用成微服务,所以在实施SOA时会遇到很多问题。 这些问题再微服务框架中得到很好的解决,你可以认为微服务架构是SOA的一种特定方法。 分布式系统 什么是分布式系统 分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器,处理更多的数据。 首先需要明确的是,只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候,且硬件的提升 (加内存、加磁盘、使用更好的CPU) 高昂到得不偿失的时候,应用程序也不能进一步优化的时候,我们才需要考虑分布式系统。因为,分布式系统要解决的问题本身就是和单机系统一样的,而由于分布式系统多节点、通过网络通信的拓扑结构,会引入很多单机系统没有的问题,为了解决这些问题又会引入更多的机制、协议,带来更多的问题。 “什么是分布式系统？这取决于看系统的角度。对于坐在键盘前使用IBM个人电脑的人来说,电脑不是一个分布式的系统。但对于在电脑主板上趴着的虫子来说,这台电脑就是一个分布式系统。” —— Leslie Lamport 复杂性 流量管理 (Traffic management) : 超时、重试、负载均衡； 安全性 (Security) : 终端用户的认证和授权； 可观察性 (Observability) : 跟踪、监控和日志。 私有数据的所有权 当多个服务直接读写数据库中同一张表时,对这些表做任何改动都需要协调这些相关服务的部署。这一点违背了服务相互独立这一原则。共享的数据存储很容易不经意间造成耦合。每个服务需要有自己的私有数据。 私有数据还能提供另一个优势: 根据服务的具体用例选择最适合的数据库技术。 每个服务都要有自己的数据服务器吗？ 不一定。每个服务需要自己的数据库,但这些数据库可共置在一台共享的数据服务器上。重点在于不应让服务知道其他服务底层数据库的存在。这样即可用一台共享数据服务器先开始开发,以后只要更改配置即可将不同服务的数据库隔离起来。 然而共享的数据服务器也可能造成一些问题。首先会形成单点故障,进而导致一大批服务同时故障,这一点绝不能掉以轻心。其次很可能因为一个服务占用太多资源而无意中对其他服务造成影响。 确定服务的边界 这个问题很复杂。每个服务应该是一种能提供某些业务能力的自治单位。 服务应当弱耦合在一起,对其他服务的依赖应尽可能低。一个服务与其他服务的任何通信都应通过公开暴露的接口 (API、事件等) 实现,这些接口需要妥善设计以隐藏内部细节。 服务应具备高内聚力。密切相关的多个功能应尽量包含在同一个服务中,这样可将服务之间的干扰降至最低。 服务应包含单一的界限上下文。界限上下文 (Bounded context) 可将某一领域的内部细节,包括该领域特定的模块封装在一起。 ...

主流持久层框架 Spring Data JPA + Hibernate Spring Boot 默认推荐，依赖 spring-boot-starter-data-jpa ORM 框架，用注解映射对象和表 自动生成 SQL，支持 JPQL / Criteria API 适合领域模型复杂的场景 MyBatis / MyBatis-Plus 半自动 ORM，SQL 写在 XML 或注解中 对 SQL 控制力强，适合复杂查询 MyBatis-Plus 提供代码生成、分页等增强功能 JOOQ 类型安全的 SQL DSL，SQL 风格写法 编译期检查 SQL，适合喜欢写 SQL 的团队 商业数据库需付费版 Spring Data JDBC 比 JPA 更轻量，无懒加载、缓存等复杂特性 SQL 更透明，适合简单 CRUD R2DBC（响应式） 非阻塞响应式驱动，配合 WebFlux 使用 依赖 spring-boot-starter-data-r2dbc 选型建议 场景 推荐 快速开发，标准 CRUD Spring Data JPA 复杂 SQL，精细控制 MyBatis-Plus 强类型 SQL，重查询业务 JOOQ 响应式架构 R2DBC 连接池 Spring Boot 默认使用 HikariCP 作为连接池。 ...

概述 JDK 17 是 Java 的长期支持版本（LTS），于 2021 年 9 月发布。相比 JDK 16，JDK 17 引入了多项新特性和改进，同时也包含了一些孵化特性的正式毕业版本。 正式特性（JEP） JEP 306: 恢复始终严格的浮点语义 将浮点运算恢复为始终严格模式（strict），删除了 strictfp 关键字的限制效果。在历史上，Java 曾因不同硬件平台的差异引入了扩展精度模式，随着现代硬件的普及，该差异不再存在，因此恢复了一致的浮点行为。 JEP 356: 增强型伪随机数生成器 提供新的接口和实现用于伪随机数生成器（PRNG），新增了 RandomGenerator 接口和多个算法实现，如 Xoshiro256PlusPlus、L64X128MixRandom 等。 RandomGenerator generator = RandomGeneratorFactory.of("L64X128MixRandom").create(); int randomInt = generator.nextInt(100); JEP 382: 新的 macOS 渲染管道 使用 Apple Metal API 实现 Java 2D 渲染管道，替代已废弃的 OpenGL API，提升在 macOS 上的图形渲染性能。 JEP 391: macOS/AArch64 移植 将 JDK 移植到 macOS/AArch64（Apple Silicon）平台，支持原生运行于 M1 及后续芯片的 Mac 电脑。 JEP 398: 废弃 Applet API 正式废弃 Applet API，标记为 @Deprecated(forRemoval = true)。浏览器早已不再支持 Java 插件，该 API 已无实际用途。 ...

JDK 8 相对于 JDK 7 引入的主要新特性： Lambda 表达式 函数式接口（Functional Interface） Stream API 方法引用（Method Reference） 默认方法（Default Method） Optional 新的日期时间 API（java.time） Nashorn JavaScript 引擎 Base64 并发增强（CompletableFuture、StampedLock、LongAdder） 重复注解（Repeating Annotations） 类型注解（Type Annotations） PermGen 移除，改用 Metaspace Lambda 表达式 Lambda 来自数学中的 λ 演算（Lambda Calculus），是函数式编程的理论基础。函数式编程的核心思想是：函数是"一等公民"，可以像普通值一样被传递、赋值、返回。JDK 8 引入 Lambda，本质上是给 Java 这门面向对象语言加入了函数式编程的能力。 Lambda 表达式允许将函数（即 Lambda 表达式本身）作为参数传递，简化匿名内部类的写法。 语法结构 (参数列表) -> 方法体 (参数列表)：传入的参数，无参数时写空括号 () ->：箭头操作符，读作 “goes to”，分隔参数列表和方法体 方法体：要执行的逻辑 Runnable 是一个接口（java.lang.Runnable），只有一个无参方法 void run()，因此参数列表为空 ()。 // JDK 7：匿名内部类写法 Runnable r = new Runnable() { @Override public void run() { System.out.println("Hello"); } }; // JDK 8：Lambda 写法，箭头右边等价于 run() 的方法体 Runnable r = () -> System.out.println("Hello"); 将函数作为参数传递 JDK 8 之前，Java 无法直接传递"一段逻辑"，只能把逻辑包装成匿名对象再传递。Lambda 表达式让你可以直接把逻辑作为参数传入方法，这就是"将函数作为参数传递"的含义。 ...

netstat 用于查看网络连接、路由表、接口统计等信息。在较新的 Linux 发行版中，推荐使用 ss 命令替代。 常用命令 # 查看所有 TCP 监听端口及对应进程 netstat -ntlp # 过滤特定端口 netstat -tulpn | grep 9100 常用选项 选项 说明 -n 以 IP 地址代替主机名显示 -t 显示 TCP 协议的连接情况 -u 显示 UDP 协议的连接情况 -l 只显示监听状态的 Socket -p 显示使用该 Socket 的程序名称和 PID -a 显示所有 Socket（包括监听和非监听） 安装 netstat 包含在 net-tools 包中： # RHEL/CentOS yum install net-tools # Debian/Ubuntu apt install net-tools

关于本站/关于我/About 本站主要是个人使用的读书笔记，因为早期使用了 Wordpress 所以申请了域名, 转到 Github + Markdown 后也保留了公开访问， 本人使用频率比较高的技术文档都有仔细整理和验证过，希望能帮助到有需要的同学。当然…也有大量的转载未整理的内容，在不断完善整理中… 收集综合症/转载 基本上是我接触过的知识的一个集合 大部分内容是转载的 70%+ 一般第一次接触的知识会找质量比较好的或者能解决问题的文章收集进来 有一部分原因是防止源站消失 (比如…已经消失的一个站点http://www.yining.org/2010/05/04/http-get-vs-post-and-thoughts/)，还有方便查找，省掉重新 Google 的过程。 有仔细读过的会修正 typo 日常遇到问题会逐渐整理，也会补充其它引用来源 有明显整理痕迹的都是仔细读过的，比如有段落标题，有代码语法高亮。 会有合并摘抄 一篇文章可能有多个引用来源， 对同一个问题也有可能有相互矛盾的来源，会补充验证后的结果。 前期不太注意知识共享协议，最近在有意识的识别有共享协议的文章并按协议转载 没有明显的知识共享协议的文章会逐渐转移到私有仓库 Obsidian + AWS S3 转载内容的 Author 会标记为 “-” 会不定期删除本人使用频率低的内容, 比如早期接触过的 ASP.net, Wordpress, PHP… 本站点对应的 GitHub 仓库: https://github.com/wiloon/blog 转载内容有侵权可以随时联系我删除 整理过的 在转载文章的基础上整理过的 记录了一部分常用的命令 平时经常使用的工具, 命令, 脚本, 使用过程中遇到问题,解决问题的过程中会频繁修改，会补充命令的示例 一般会有语法高亮 有段落标注 可能有 N 个引用来源 以 Tag(remix) 方式标记整理过的转载内容 – 逐渐整理中，要花些时间从收集的文档里捞出来。 日常记录 少量的原创文章或原创比例比较高的文档 日常遇到的问题和解决过程 以 Tag(original) 方式标记 – 逐渐整理中，要花些时间从收集的文档里捞出来。 Author 会标记为 “w1100n” Blog 实现 Markdown GitHub GitHub Action Hugo PaperMod theme Cloudflare Pages 关于我 王越 ...

什么是 Harness Engineering Harness Engineering 是一种以"脚手架优先"为核心思想的软件开发方法，尤其在 AI 辅助开发场景下越来越受到关注。 “Harness”（脚手架/支撑框架）这个词借用自工程领域，在软件中指围绕核心系统搭建的一套结构化支撑层，包括： 明确的文档约定（说明系统当前状态、设计决策） 测试框架和实验入口（可快速验证变更） 状态记录文件（捕捉项目在某个时间点的快照） 接口契约和边界定义 它的目标是让代码库对人和 AI 助手都更"可理解、可修改、可安全演进"。 状态锚点是什么 状态锚点（State Anchor） 是 Harness Engineering 的核心实践之一。 它是一个显式的文档文件（通常命名为 harness-state.md、project-state.md 等），用来在某个时间点精确记录系统的当前状态，就像 Git commit 对代码的作用，它对"上下文"做了一次快照。 典型内容 一个状态锚点文件通常包含： ## 当前状态（2026-04-09） ### 已完成 - [x] 核心数据模型定义完毕 - [x] API 接口初版上线 ### 进行中 - [ ] 用户认证模块（50%） ### 已知问题 - /api/user 接口在并发场景下偶发 500 ### 下一步 - 完成认证模块 → 接入集成测试 → 上线 v0.2 状态锚点的作用 1. 消除"现在在哪"的认知负担 每次回到一个项目，最耗时的事情不是写代码，而是重建上下文：“上次做到哪了？““这个模块稳定了吗？““还有什么坑没踩完？” ...

安装 Claude Code # macOS 用 brew 安装（推荐） brew install --cask claude-code # 或安装最新版 brew install --cask claude-code@latest # 用 npm 安装 npm install -g @anthropic-ai/claude-code 安装 cc-switch（多账号切换工具） brew install --cask cc-switch 安装后从 Launchpad 或用以下命令启动： open -a cc-switch 认证冲突处理 cc-switch 会设置 ANTHROPIC_AUTH_TOKEN 环境变量，若同时存在 claude /login 的 key，启动时会出现： ⚠ Auth conflict: Both a token (ANTHROPIC_AUTH_TOKEN) and an API key (/login managed key) are set. 想用 cc-switch 管理的账号： claude /logout 想用 /login 的 key： ...

grub 判断是否由 grub 引导 journalctl -b | grep -i grub https://www.gnu.org/software/grub/manual/grub/grub.html#Simple-configuration GRUB 来自 GRand Unified Bootloader 的缩写。它的功能是在启动时从 BIOS 接管掌控、加载自身、加载 Linux 内核到内存，然后再把执行权交给内核。一旦内核开始掌控，GRUB 就完成了它的任务，也就不再需要了。 GRUB 支持多种 Linux 内核，并允许用户在启动时通过菜单在其中选择。 GRUB 菜单提供了一个 “救援rescue” 内核，用于故障排除或者由于某些原因导致的常规内核不能完成启动过程。 grub.cfg 文件是 GRUB 配置文件。它由 grub2-mkconfig 程序根据用户的配置使用一组主配置文件以及 grub 默认文件而生成。/boot/grub2/grub.cfg 文件在 Linux 安装时会初次生成，安装新内核时又会重新生成。 grub.cfg 文件包括了类似 Bash 脚本的代码以及一个按照安装顺序排序的已安装内核列表。 grub.cfg 的主要配置文件都在 /etc/grub.d 目录。该目录中的每个文件都包含了最终会整合到 grub.cfg 文件中的 GRUB 代码。这些配置文件的命名模式以排序方式设计，这使得最终的 grub.cfg 文件可以按正确的顺序整合而成。每个文件都有注释表明该部分的开始和结束，这些注释也是最终的 grub.cfg 文件的一部分，从而可以看出每个部分是由哪个文件生成。 grub config file path check grub version grub2-install --version GRUB1.配置文件: /boot/grub/menu.lst GRUB2.配置文件: /boot/grub/grub.cfg，/etc/grub.d/下是生成配置文件的模板，/etc/default/grub是生成配置文件的参数 If you change this file, run ‘update-grub’ afterward to update ...

常见排序算法： 冒泡排序 选择排序 插入排序 希尔排序 快速排序 归并排序 堆排序 计数排序 桶排序 基数排序 推荐学习顺序： 冒泡 → 选择 → 插入 → 快速 → 归并 → 堆 冒泡排序 Bubble Sort 相邻元素两两比较，大的往后"冒泡"，每轮将最大值沉到末尾。 时间复杂度：O(n²) 空间复杂度：O(1) 稳定排序 def bubble_sort(arr): n = len(arr) for i in range(n): for j in range(n - i - 1): if arr[j] > arr[j + 1]: arr[j], arr[j + 1] = arr[j + 1], arr[j] return arr # 测试 arr = [64, 34, 25, 12, 22, 11, 90] print("排序前:", arr) bubble_sort(arr) print("排序后:", arr) 执行过程（以 [5, 3, 1] 为例）： 第1轮： j=0: 5 > 3，交换 → [3, 5, 1] j=1: 5 > 1，交换 → [3, 1, 5] ← 最大值 5 沉底 第2轮： j=0: 3 > 1，交换 → [1, 3, 5] ← 次大值 3 到位 第3轮：只剩1个，已有序 外层 i 控制轮数，每轮确定一个最大值的位置 内层 n - i - 1 让已排好的尾部不再参与比较 a, b = b, a 是 Python 交换变量的惯用写法 选择排序 Selection Sort 每轮从未排序部分找最小值，放到已排序部分的末尾。 ...

between and BETWEEN 用以查询确定范围的值，这些值可以是数字，文本或日期 。 BETWEEN 运算符是闭区间的：包括开始 和 结束值 。 not between 则是不包含前后边界的 select select * from table0 where column0!=''; !=’’ 会过滤掉值为 null 的数据. The reason is simple: nulls are neither equal, nor not equal, to anything. This makes sense when you consider that null means “unknown”, and the truth of a comparison to an unknown value is also unknown. The corollary is that: null = null is not true null = some_value is not true null != some_value is not true The two special comparisons IS NULL and IS NOT NULL exist to deal with testing if a column is, or is not, null. No other comparisons to null can be true. ...

原型模式（Prototype Pattern）是一种创建型模式，通过复制（克隆）一个已有对象来创建新对象，而不是通过 new 重新实例化。 核心思想 当创建一个对象的代价较大（如需要复杂初始化、数据库查询、网络请求等）时，可以先创建一个原型对象，后续通过克隆该原型来快速获得新对象。 角色 Prototype（抽象原型）：声明克隆方法 clone()。 ConcretePrototype（具体原型）：实现克隆方法，返回自身的副本。 Client（客户端）：通过调用原型的克隆方法来创建新对象。 浅克隆与深克隆 浅克隆（Shallow Clone） 深克隆（Deep Clone） 基本类型字段 复制值 复制值 引用类型字段 复制引用（共享对象） 递归复制，独立对象 修改互不影响 ❌ 引用字段会互相影响 ✅ 完全独立 示例：细胞克隆 Java 通过实现 Cloneable 接口来支持浅克隆： public class Cell implements Cloneable { private String cellWall; // 细胞壁 private String cellMembrane; // 细胞膜 private String cellularTissue; // 细胞组织 public String getCellWall() { return cellWall; } public void setCellWall(String cellWall) { this.cellWall = cellWall; } // 其他 getter/setter 省略 @Override public Cell clone() { try { return (Cell) super.clone(); } catch (CloneNotSupportedException e) { throw new InternalError(e.getMessage()); } } } 客户端使用： ...

中介者模式（Mediator Pattern）定义一个中介对象来封装一系列对象之间的交互，使各对象不需要显式地相互引用，从而降低耦合度，并可以独立地改变它们之间的交互。 核心思想 当系统中多个对象之间存在复杂的多对多交互时，对象之间的依赖关系会形成网状结构，难以维护。中介者模式将这种网状结构转化为星形结构——所有对象只与中介者通信，由中介者协调各对象之间的交互。 # 不使用中介者：网状结构 A ←→ B A ←→ C B ←→ C B ←→ D ... # 使用中介者：星形结构 A → Mediator ← B ↑ ↓ C D 角色 Mediator（抽象中介者）：定义各同事对象通信的接口。 ConcreteMediator（具体中介者）：实现协调逻辑，持有所有同事对象的引用。 Colleague（同事类）：每个同事只知道中介者，通过中介者与其他同事交互。 示例：聊天室 聊天室是中介者模式的典型场景：用户之间不直接通信，而是通过聊天室（中介者）转发消息。 抽象中介者： public interface ChatRoom { void sendMessage(String message, User sender); void addUser(User user); } 具体中介者： import java.util.ArrayList; import java.util.List; public class ChatRoomImpl implements ChatRoom { private final List<User> users = new ArrayList<>(); @Override public void addUser(User user) { users.add(user); } @Override public void sendMessage(String message, User sender) { for (User user : users) { if (user != sender) { user.receive(message, sender.getName()); } } } } 同事类： ...

责任链模式（Chain of Responsibility）将请求沿着一条处理者链传递，每个处理者决定是否处理该请求，或将其传递给链上的下一个处理者。请求的发送者无需知道最终由哪个处理者来处理，从而实现了发送者与接收者的解耦。 核心思想 不使用责任链时，请求方往往需要硬编码逻辑来判断应该由哪个对象处理，导致紧耦合和大量条件判断。责任链将这些处理者串联起来，请求沿链传递，直到被某个处理者处理（或到达链尾）。 角色 Handler（抽象处理者）：定义处理请求的接口，通常包含设置下一个处理者的方法。 ConcreteHandler（具体处理者）：实现处理逻辑，决定自己是否处理请求，如果不处理则转发给下一个处理者。 Client（客户端）：构建责任链并向链头发起请求。 示例：请假审批 不同级别的请假天数由不同层级的领导审批：组长审批 1 天以内，经理审批 3 天以内，总监审批 7 天以内，超过 7 天不予批准。 抽象处理者： public abstract class Approver { protected Approver next; public Approver setNext(Approver next) { this.next = next; return next; } public abstract void approve(int days); } 具体处理者： public class TeamLeader extends Approver { @Override public void approve(int days) { if (days <= 1) { System.out.println("组长批准了 " + days + " 天假。"); } else if (next != null) { next.approve(days); } } } public class Manager extends Approver { @Override public void approve(int days) { if (days <= 3) { System.out.println("经理批准了 " + days + " 天假。"); } else if (next != null) { next.approve(days); } } } public class Director extends Approver { @Override public void approve(int days) { if (days <= 7) { System.out.println("总监批准了 " + days + " 天假。"); } else { System.out.println("请假 " + days + " 天，超出审批权限，不予批准。"); } } } 客户端构建链并发起请求： ...

状态模式（State Pattern）允许一个对象在其内部状态发生改变时改变其行为，使该对象看起来像是改变了它的类。 核心思想 在不使用状态模式的情况下，对象的行为往往通过大量 if-else 或 switch 判断当前状态来分支处理，导致代码臃肿、难以扩展。状态模式将每种状态封装成独立的类，对象将行为委托给当前状态对象，状态切换时只需替换状态对象即可。 角色 Context（上下文）：持有当前状态的引用，对外暴露行为接口，将行为委托给当前状态对象处理。 State（抽象状态）：定义所有具体状态共同的接口。 ConcreteState（具体状态）：实现 State 接口，封装该状态下的行为，并在必要时触发状态转换。 示例：交通灯 交通灯有红、黄、绿三种状态，不同状态下的行为不同，且状态之间按规则流转。 抽象状态接口： public interface TrafficLightState { void handle(TrafficLight light); String getColor(); } 具体状态类： public class RedState implements TrafficLightState { @Override public void handle(TrafficLight light) { System.out.println("红灯停。"); light.setState(new GreenState()); } @Override public String getColor() { return "红"; } } public class GreenState implements TrafficLightState { @Override public void handle(TrafficLight light) { System.out.println("绿灯行。"); light.setState(new YellowState()); } @Override public String getColor() { return "绿"; } } public class YellowState implements TrafficLightState { @Override public void handle(TrafficLight light) { System.out.println("黄灯警示，请注意。"); light.setState(new RedState()); } @Override public String getColor() { return "黄"; } } Context（上下文）类： ...

策略模式（Strategy Pattern）定义了一系列算法，把这些算法一个个封装成单独的类，使它们可以相互替换，且算法的改变不会影响使用算法的客户。 策略模式重点是封装不同的算法和行为，不同的场景下可以相互替换。策略模式是开闭原则的体现——对扩展开放，对修改关闭：新增策略时不影响其他类，且场景类只依赖抽象而不依赖具体实现。 示例：字符串替换策略 这里以字符串替换为例：读取一个文件后，需要替换其中的变量再输出。替换方式可能有多种，我们用策略模式来支持运行时切换。 首先，建立抽象策略类 RepTempRule，定义公用变量和方法： public abstract class RepTempRule { protected String oldString = ""; public void setOldString(String oldString) { this.oldString = oldString; } protected String newString = ""; public String getNewString() { return newString; } public abstract void replace() throws Exception; } 现在有两个具体策略：将文本中的 aaa 替换成 bbbb，或替换成 ccc： public class RepTempRuleOne extends RepTempRule { @Override public void replace() throws Exception { newString = oldString.replaceFirst("aaa", "bbbb"); System.out.println("this is replace one"); } } public class RepTempRuleTwo extends RepTempRule { @Override public void replace() throws Exception { newString = oldString.replaceFirst("aaa", "ccc"); System.out.println("this is replace two"); } } 算法解决类，提供运行时自由选择和切换算法的能力： ...

模板方法模式是类的行为模式。准备一个抽象类，将部分逻辑以具体方法以及具体构造函数的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。这就是模板方法模式的用意。 模式结构 模板方法模式是所有模式中最为常见的几个模式之一，是基于继承的代码复用的基本技术。 模板方法模式需要开发抽象类和具体子类的设计师之间的协作。一个设计师负责给出一个算法的轮廓和骨架，另一些设计师则负责给出这个算法的各个逻辑步骤。代表这些具体逻辑步骤的方法称做基本方法（primitive method）；而将这些基本方法汇总起来的方法叫做模板方法（template method），这个设计模式的名字就是从此而来。 模板方法所代表的行为称为顶级行为，其逻辑称为顶级逻辑。 这里涉及到两个角色： 抽象模板（Abstract Template） 角色的责任： 定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤。 定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。 具体模板（Concrete Template） 角色的责任： 实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤。 每一个抽象模板角色都可以有任意多个具体模板角色与之对应，而每一个具体模板角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。 基础示例 抽象模板角色类，abstractMethod()、hookMethod() 等基本方法是顶级逻辑的组成步骤，这个顶级逻辑由 templateMethod() 方法代表。 public abstract class AbstractTemplate { /** * 模板方法 */ public void templateMethod() { // 调用基本方法 abstractMethod(); hookMethod(); concreteMethod(); } /** * 基本方法的声明（由子类实现） */ protected abstract void abstractMethod(); /** * 基本方法（空方法） */ protected void hookMethod() {} /** * 基本方法（已经实现） */ private final void concreteMethod() { // 业务相关的代码 } } 具体模板角色类实现了父类所声明的基本方法，abstractMethod() 方法所代表的就是强制子类实现的剩余逻辑，而 hookMethod() 方法是可选择实现的逻辑。 ...

概念 通常，客户类通过类的接口访问它提供的服务。有时，现有的类可以提供客户类需要的功能，但它所提供的接口不一定是客户类所期望的——可能接口过于详细、缺少细节，或者名称不匹配。 在这种情况下，需要将现有接口转化为客户类期望的接口，从而保证对现有类的重用。适配器模式（Adapter Pattern）通过定义一个包装类来完成这种转化： Target：客户类期望的接口 Adaptee：现有的、接口不兼容的类 Adapter：包装 Adaptee，实现 Target 接口 当客户类调用 Adapter 的方法时，Adapter 内部转而调用 Adaptee 的对应方法，这个过程对客户类透明。 类适配器 vs 对象适配器 类适配器 对象适配器 实现方式 继承 Adaptee 组合 Adaptee 灵活性 静态绑定，无法适配 Adaptee 子类 可适配 Adaptee 及其所有子类 方法重载 可重载 Adaptee 的方法 不能直接重载，但可在包装方法中修改行为 可见性 客户类可见 Adaptee 的 public 方法 客户类与 Adaptee 完全解耦 Java 限制 仅适用于 Target 是接口（Java 单继承） Target 可以是接口或抽象类 类适配器示例 Adapter 通过继承 Adaptee 来复用其接口： // Target：客户类期望的接口 public interface Target { void sampleOperation1(); } // Adaptee：现有的第三方类，接口不兼容 public class Adaptee { public void sampleOperation2() { System.out.println("Adaptee.sampleOperation2()"); } } // Adapter：继承 Adaptee，实现 Target public class Adapter extends Adaptee implements Target { @Override public void sampleOperation1() { this.sampleOperation2(); } } // Client public class Client { public static void main(String[] args) { Target target = new Adapter(); target.sampleOperation1(); } } 对象适配器示例 Adapter 通过组合 Adaptee 来复用其接口： ...

代理模式, proxy pattern 为其他对象提供一种代理以控制对这个对象的访问。 代理模式，即Proxy，它和 Adapter 模式很类似。我们先回顾Adapter模式，它用于把A接口转换为B接口： Adapter 模式 public BAdapter implements B { private A a; public BAdapter(A a) { this.a = a; } public void b() { a.a(); } } Proxy模式 而Proxy模式不是把A接口转换成B接口，它还是转换成A接口： public AProxy implements A { private A a; public AProxy(A a) { this.a = a; } public void a() { this.a.a(); } } 看起来 Proxy 只是把 A 接口又包了一层，这有什么意义呢？ ...