AI-Assisted

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 接口又包了一层，这有什么意义呢？ ...

概念 看到"门面"这个词，大家一定都觉得很熟悉。日常生活中的"门面"就是我们买东西的地方，它跟各种商品的生产商打交道，收集商品后再卖给我们。如果没有"门面"，我们将不得不直接跟各种各样的生产商买商品。 Facade 模式正是这样一个"门面"：我们本来需要与后台的多个类或接口打交道，而 Facade 模式在客户端和后台之间插入一个中间层——门面，这个门面跟后台的多个类或接口打交道，客户端只需要跟门面打交道即可。 Facade 类是一个简化的用户接口，它和后台中的多个类产生依赖关系，而客户类则只跟 Facade 类产生依赖关系。后台的开发者熟悉自己开发的各个类，容易解决与多个类的依赖关系；而使用者不太熟悉后台的各个类，通过 Facade 可以大大降低使用难度。 情况一：功能分布在多个无关类中 客户类要使用的功能分布在多个类中，客户必须先初始化各个类才能使用。这时适合将这些功能集中在一个 Facade 类里，同时替用户做初始化工作。 场景： 商店里出售三种商品——衣服、电脑和手机，分别由各自的生产厂商提供。 各厂商类： public class CoatFactory { public Coat saleCoat() { // ... return coat; } } public class ComputerFactory { public Computer saleComputer() { // ... return computer; } } public class MobileFactory { public Mobile saleMobile() { // ... return mobile; } } 没有商店时，客户需要分别跟各厂商打交道： ...

概念 组合模式（Composite Pattern）将对象组合成树状层次结构，使客户端对单个对象（叶子节点）和组合对象（容器节点）具有一致的访问方式。 核心思想：部分与整体的统一接口。 角色： Component：抽象组件，定义叶子和容器的公共接口 Leaf：叶子节点，没有子节点，实现具体操作 Composite：容器节点，包含子组件，将操作委托给子节点 示例：文件系统 文件系统是 Composite 模式的经典场景——文件夹可以包含文件或其他文件夹，但对外都提供统一的 getSize() 接口。 // Component public interface FileSystemNode { String getName(); long getSize(); void print(String indent); } // Leaf public class File implements FileSystemNode { private final String name; private final long size; public File(String name, long size) { this.name = name; this.size = size; } @Override public String getName() { return name; } @Override public long getSize() { return size; } @Override public void print(String indent) { System.out.println(indent + "📄 " + name + " (" + size + " bytes)"); } } // Composite public class Directory implements FileSystemNode { private final String name; private final List<FileSystemNode> children = new ArrayList<>(); public Directory(String name) { this.name = name; } public void add(FileSystemNode node) { children.add(node); } public void remove(FileSystemNode node) { children.remove(node); } @Override public String getName() { return name; } @Override public long getSize() { return children.stream() .mapToLong(FileSystemNode::getSize) .sum(); } @Override public void print(String indent) { System.out.println(indent + "📁 " + name + "/"); for (FileSystemNode child : children) { child.print(indent + " "); } } } // Client public class Client { public static void main(String[] args) { Directory root = new Directory("root"); Directory src = new Directory("src"); src.add(new File("Main.java", 1200)); src.add(new File("Utils.java", 800)); Directory resources = new Directory("resources"); resources.add(new File("config.yml", 300)); resources.add(new File("banner.txt", 50)); root.add(src); root.add(resources); root.add(new File("README.md", 500)); root.print(""); System.out.println("Total size: " + root.getSize() + " bytes"); } } 输出： ...

创建者模式, 建造者模式, Builder 定义: 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示 使用场景 多个部件或零件，都可以装配到一个对象中，但产生的结果又不相同时。 当初始化一个对象特别复杂的时候，比如参数多，而且很多参数都有默认值。 它分为抽象建造者 (Builder) 角色、具体建造者 (ConcreteBuilder) 角色、导演者 (Director) 角色、产品 (Product) 角色四个角色。 抽象建造者 (Builder) 角色: 给 出一个抽象接口，以规范产品对象的各个组成成分的建造。 具体建造者 (ConcreteBuilder) 角色: 要完成的任务包括: 1.实现抽象建造者Builder所声明的接口，给出一步一步地完成创建产品实例的操作。2.在建造过程完成后，提供产品的实例。 导演者 (Director) 角色: 担任这个角色的类调用具体建造者角色以创建产品对象。 产品 (Product) 角色: 产品便是建造中的复杂对象。 对于Builder模式很简单，但是一直想不明白为什么要这么设计，为什么要向builder要Product而不是向知道建造过程的Director要。刚才google到一篇文章，总算清楚了。在这里转贴一下这位richardluo的比喻。 简单地说，就好象我要装修一套房子，可是我不懂施工——水电怎么走、木作怎么做，每个工种都有自己专注的领域；也不懂整体设计——用什么风格、先做哪道工序、各部分如何协调，这是设计师的职责。于是我需要找一支装修队，各工种各司其职；还得找个设计师，他来规划整体方案、协调各工种按图施工，而设计师本身不动手，只负责下命令。最后，我可以向工人要装修好的房间了。在这个过程中，设计师手里什么都没有，只有图纸和指令，所以要房间也是跟工人要，记住了！ 以下是richardluo的代码，我根据他的思路加上了相应的注释。 定义工人接口，即一支装修队所需具备的通用技能。 // 工人接口。水电工负责布线，木工负责木作，油漆工负责涂装。 // 装修完成后，由装修队把房间交还给房主。 public interface Builder { void doElectrical(); // 水电工 void doCarpentry(); // 木工 void doPainting(); // 油漆工 Room getRoom(); } 定义设计师（Director），他持有图纸，协调装修队按方案施工。 // 设计师（Director）。持有图纸，规定施工顺序，但不亲自动手。 public class Designer { public void coordinate(Builder builder) { builder.doElectrical(); builder.doCarpentry(); builder.doPainting(); } } 装修队（ConcreteBuilder），负责具体的施工实施。 // 各专职工人 class ElectricalWorker { public String work() { return "electrical done"; } } class Carpenter { public String work() { return "carpentry done"; } } class Painter { public String work() { return "painting done"; } } // 装修队（ConcreteBuilder）。由水电工、木工、油漆工组成，各司其职。 // 装修完成后，由装修队把房间交还给房主。 public class WorkerTeam implements Builder { private ElectricalWorker electrician = new ElectricalWorker(); private Carpenter carpenter = new Carpenter(); private Painter painter = new Painter(); private String electrical = ""; private String carpentry = ""; private String painting = ""; public void doElectrical() { electrical = electrician.work(); } public void doCarpentry() { carpentry = carpenter.work(); } public void doPainting() { painting = painter.work(); } // 把装修好的房间交还给房主 public Room getRoom() { if (!electrical.equals("") && !carpentry.equals("") && !painting.equals("")) { System.out.println("room ready!"); return new Room(); } else { return null; } } } 房主（Client），雇人、收房。 // 房主。聘请一支装修队和一位设计师，让设计师协调装修队按图施工，最后从装修队手上收房。 public class Client { public static void main(String[] args) { Builder team = new WorkerTeam(); Designer designer = new Designer(); designer.coordinate(team); team.getRoom(); } } 好了，我觉得这样大概能说明白了。不知各位觉得如何呢？或者有更好的应用场景解释，敬请赐教。 ...

SOLID 是面向对象设计的五大基本原则的首字母缩写，由 Robert C. Martin（Uncle Bob）整理归纳。这五个原则是编写可维护、可扩展代码的基础。 S — 单一职责原则 (Single Responsibility Principle, SRP) 一个类应该只有一个引起它变化的原因。 一个类只做一件事。如果一个类承担了多个职责，那么每个职责的变化都可能影响这个类，导致它越来越难以维护。 反例： 简单工厂模式中的工厂类 Driver 同时负责判断车型和创建所有车对象，违反了单一职责。 O — 开闭原则 (Open-Closed Principle, OCP) 软件实体应该对扩展开放，对修改封闭。 添加新功能时，应该通过新增代码实现，而不是修改已有代码。详见开闭原则。 反例： 简单工厂的 if/else 判断链，每新增一种产品都要修改工厂方法。 L — 里氏替换原则 (Liskov Substitution Principle, LSP) 子类必须能够替换其父类，且程序行为不变。 任何使用父类的地方，换成子类后程序应该仍然正确运行。子类不应该破坏父类的契约。 示例： Benze 和 Bmw 都实现了 Car 接口，客户端代码使用 Car 类型，无论实际是哪种车，drive() 都能正确调用。 I — 接口隔离原则 (Interface Segregation Principle, ISP) 客户端不应该被迫依赖它不使用的方法。 接口应该尽量细化，不要把不相关的方法放在同一个接口里。大接口应该拆分成多个小接口，让实现类只需要关心自己用到的方法。 反例： 一个包含 fly()、swim()、run() 的 Animal 接口，鱼类被迫实现 fly() 和 run()。 D — 依赖倒置原则 (Dependency Inversion Principle, DIP) 高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。 ...

开闭原则 开闭原则(Open-Close Principle/OCP)是面向对象设计中"可复用设计"的基石，是面向对象设计中最重要的原则之一，其它很多的设计原则都是实现开闭原则的一种手段。 1988年，Bertrand Meyer在他的著作《Object Oriented Software Construction》中提出了开闭原则，它的原文是这样: “Software entities should be open for extension,but closed for modification”。翻译过来就是: “软件实体应当对扩展开放，对修改关闭”。这句话说得略微有点专业，我们把它讲得更通俗一点，也就是: 软件系统中包含的各种组件，例如模块 (Modules) 、类 (Classes) 以及功能 (Functions) 等等，应该在不修改现有代码的基础上，引入新功能。开闭原则中"开"，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中"闭"，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。实现开闭原则的关键就在于"抽象"。把系统的所有可能的行为抽象成一个抽象底层，这个抽象底层规定出所有的具体实现必须提供的方法的特征。作为系统设计的抽象层，要预见所有可能的扩展，从而使得在任何扩展情况下，系统的抽象底层不需修改；同时，由于可以从抽象底层导出一个或多个新的具体实现，可以改变系统的行为，因此系统设计对扩展是开放的。 我们在软件开发的过程中，一直都是提倡需求导向的。这就要求我们在设计的时候，要非常清楚地了解用户需求，判断需求中包含的可能的变化，从而明确在什么情况下使用开闭原则。 关于系统可变的部分，还有一个更具体的对可变性封装原则 (Principle of Encapsulation of Variation, EVP) ，它从软件工程实现的角度对开闭原则进行了进一步的解释。EVP要求在做系统设计的时候，对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装。 我们在实际开发过程的设计开始阶段，就要罗列出来系统所有可能的行为，并把这些行为加入到抽象底层，根本就是不可能的，这么去做也是不经济的，费时费力。另外，在设计开始阶段，对所有的可变因素进行预计和封装也不太现实，也是很难做得到。所以，开闭原则描绘的愿景只是一种理想情况或是极端状态，现实世界中是很难被完全实现的。我们只能在某些组件，在某种程度上符合开闭原则的要求。 通过以上的分析，对于开闭原则，我们可以得出这样的结论: 虽然我们不可能做到百分之百的封闭，但是在系统设计的时候，我们还是要尽量做到这一点。 对于软件系统的功能扩展，我们可以通过继承、重载或者委托等手段实现。以接口为例，它对修改就是是封闭的，而对具体的实现是开放的，我们可以根据实际的需要提供不同的实现，所以接口是符合开闭原则的。如果一个软件系统符合开闭原则的，那么从软件工程的角度来看，它至少具有这样的好处: 可复用性好。 我们可以在软件完成以后，仍然可以对软件进行扩展，加入新的功能，非常灵活。因此，这个软件系统就可以通过不断地增加新的组件，来满足不断变化的需求。 可维护性好。 由于对于已有的软件系统的组件，特别是它的抽象底层不去修改，因此，我们不用担心软件系统中原有组件的稳定性，这就使变化中的软件系统有一定的稳定性和延续性。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。因此，针对开闭原则的实现方法，一直都有面向对象设计的大师费尽心机，研究开闭原则的实现方式。后面要提到的里氏代换原则 (LSP) 、依赖倒转原则 (DIP) 、接口隔离原则 (ISP) 以及抽象类 (Abstract Class) 、接口(Interface)等等，都可以看作是开闭原则的实现方法。 http://baike.baidu.com/view/866233.htm