架构与方法 on 小盒子的技术分享

一文讲透 GoF 的 23 种设计模式之工厂方法

Fri, 27 Feb 2026 23:00:00 +0000

一文讲透 GoF 的 23 种设计模式之工厂方法

工厂方法（Factory Method）是创建型模式

定义

用一句话概括工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。它让类的实例化推迟到了子类。

简单工厂

了解工厂方法模式前，我们先了解下简单工厂，既然叫简单工厂，那自然很 “简单”。

它的核心思想非常直接：专门定义一个类（包揽大权），通过接收不同的参数，用 switch 或 if-else 来决定创建并返回哪一种具体的产品实例。

假设我们在开发一个 AI 应用，需要根据不同场景创建不同类型的 AI Agent（比如负责对话的 Agent，和负责处理数据的 Agent）。

第一步：定义产品的共同接口和具体实现

 1⚡ java片段// 1. 抽象产品
 2public interface AIAgent {
 3 voidexecuteTask();
 4}
 5
 6// 2. 具体产品 A：聊天助理
 7publicclass ChatAgent implements AIAgent {
 8 @Override
 9 publicvoidexecuteTask() {
10 System.out.println("ChatAgent: 正在与用户进行自然语言对话...");
11 }
12}
13
14// 2. 具体产品 B：数据分析助理
15publicclass DataAnalysisAgent implements AIAgent {
16 @Override
17 publicvoidexecuteTask() {
18 System.out.println("DataAnalysisAgent: 正在提取并分析核心数据...");
19 }
20}

第二步：创建“简单工厂”类

 1⚡ java片段// 3. 简单工厂类 (通常使用静态方法)
 2publicclass AIAgentFactory {
 3 
 4 // 根据传入的类型参数，决定实例化哪个具体的 Agent
 5 publicstatic AIAgent createAgent(String agentType) {
 6 if ("chat".equalsIgnoreCase(agentType)) {
 7 return new ChatAgent();
 8 } elseif ("data".equalsIgnoreCase(agentType)) {
 9 return new DataAnalysisAgent();
10 } else {
11 throw new IllegalArgumentException("未知的 Agent 类型: " + agentType);
12 }
13 }
14}

第三步：客户端调用

 1⚡ java片段public class Client {
 2 public static void main(String[] args) {
 3 // 客户端不需要知道 ChatAgent 和 DataAnalysisAgent 是怎么被 new 出来的
 4 // 只需要告诉工厂：“给我一个 chat 类型的 Agent”
 5 AIAgent agent1 = AIAgentFactory.createAgent("chat");
 6 agent1.executeTask();
 7
 8 AIAgent agent2 = AIAgentFactory.createAgent("data");
 9 agent2.executeTask();
10 }
11}

结合代码，我们可以很直观地看到它的特点：

●优点（省事、解耦）：客户端彻底和具体的实现类解耦了。你不需要在业务代码里到处写 new ChatAgent()，把“创建对象”的脏活累活全交给了工厂。

●缺点（牵一发而动全身）：它严重违反了“开闭原则”（对扩展开放，对修改关闭）。假设我们现在要引入一个新的 CodingAgent（写代码助手），除了要新建产品类，你必须去修改 AIAgentFactory 里面的 if-else 代码。一旦产品种类极其庞大，这个工厂类就会变得非常臃肿且难以维护。

正是为了解决简单工厂“违反开闭原则”的这个致命缺点，才演进出了工厂方法模式（把这一个大工厂，拆成了一个个不用改代码、只需新增的具体小工厂）。

工厂方法模式的结构与角色

工厂方法模式主要包含四个角色：

●抽象产品 (Product)：定义产品的统一接口。

●具体产品 (Concrete Product)：实现抽象产品接口的具体类。

●抽象工厂 (Creator)：声明返回产品对象的工厂方法。

●具体工厂 (Concrete Creator)：重写工厂方法，返回具体的实例化产品

Java 代码实现

1. 定义产品（大模型客户端）

 1⚡ java片段// 抽象产品：统一的大模型调用接口
 2public interface LLMClient {
 3 String generate(String prompt);
 4}
 5
 6// 具体产品 A：Claude 客户端
 7publicclass ClaudeClient implements LLMClient {
 8 private String modelVersion;
 9 
10 publicClaudeClient(String modelVersion) { this.modelVersion = modelVersion; }
11
12 @Override
13 public String generate(String prompt) {
14 return"[Claude " + modelVersion + "] 思考并返回结果...";
15 }
16}
17
18// 具体产品 B：OpenAI 客户端
19publicclass OpenAIClient implements LLMClient {
20 private String endpoint;
21 
22 publicOpenAIClient(String endpoint) { this.endpoint = endpoint; }
23
24 @Override
25 public String generate(String prompt) {
26 return"[OpenAI API] 处理输入并返回结果...";
27 }
28}

2. 定义创建者（核心：业务骨架 + 工厂方法）

这里是关键：AgentWorkflow 不是一个纯粹的“工厂类”，它是业务类，工厂方法只是它的一部分。

 1⚡ java片段// 抽象创建者：Agent 工作流骨架
 2public abstract class AgentWorkflow {
 3
 4 // 核心业务逻辑：定义了标准的处理流程（这其实也是个模板方法）
 5 publicvoidprocessTask(String taskContext) {
 6 System.out.println("=== 1. 解析任务上下文，提取关键信息 ===");
 7 
 8 // 【灵魂所在】：这里调用工厂方法，拿到一个产品对象。
 9 // 父类在此刻完全不知道自己拿到的是 Claude 还是 OpenAI。
10 LLMClient client = createLLMClient();
11 
12 System.out.println("=== 2. 请求大模型进行推理 ===");
13 String result = client.generate(taskContext);
14 
15 System.out.println("=== 3. 结果后处理并落库 ===\n" + result + "\n");
16 }
17
18 // 【工厂方法】：将实例化具体产品的职责，推迟到子类去实现
19 protected abstract LLMClient createLLMClient();
20}

3. 定义具体创建者（子类重写工厂方法）

 1⚡ java片段// 具体创建者 A：基于 Claude 的工作流
 2publicclass ClaudeAgentWorkflow extends AgentWorkflow {
 3 @Override
 4 protected LLMClient createLLMClient() {
 5 // 这里封装 Claude 特有的复杂初始化逻辑（比如加载凭证、设置代理等）
 6 System.out.println(" -> [工厂方法] 正在初始化 Claude 客户端环境...");
 7 return new ClaudeClient("3.5-Sonnet");
 8 }
 9}
10
11// 具体创建者 B：基于 OpenAI 的工作流
12publicclass OpenAIAgentWorkflow extends AgentWorkflow {
13 @Override
14 protected LLMClient createLLMClient() {
15 System.out.println(" -> [工厂方法] 正在构建 OpenAI 客户端环境...");
16 return new OpenAIClient("https://api.openai.com/v1");
17 }
18}

4. 客户端调用

 1⚡ java片段public class Client {
 2 publicstaticvoidmain(String[] args) {
 3 String task = "编写一段 Python Web 框架对比报告";
 4
 5 // 场景 1：启动基于 Claude 的 Agent 工作流
 6 AgentWorkflow claudeWorkflow = new ClaudeAgentWorkflow();
 7 claudeWorkflow.processTask(task);
 8
 9 // 场景 2：切换为基于 OpenAI 的 Agent 工作流
10 AgentWorkflow openaiWorkflow = new OpenAIAgentWorkflow();
11 openaiWorkflow.processTask(task);
12 }
13}

如果你回看之前的例子，你会发现这个 Demo 解决了一个架构设计上的核心痛点：控制反转 (IoC) 的雏形。

在 AgentWorkflow 这个父类中，业务主流程已经被彻底固化并复用（processTask 方法）。如果在未来，业务需求要求你接入一个全新的本地开源模型（比如 DeepSeek），你不需要修改任何现有的主流程代码，只需要：

●新建一个 DeepSeekClient（实现 LLMClient）。

●新建一个 DeepSeekAgentWorkflow，重写 createLLMClient() 方法返回这个新 Client。

这才是工厂方法模式真正强大的地方：它是为了让高层模块（业务骨架）能够独立于底层模块（具体产品）的创建而存在，从而支撑起大型框架的扩展性。 JDK 里的 Iterable 接口和它的 iterator() 方法，本质上就是这种工厂方法模式的经典体现。

什么时候用?

●你写的“父类流程”需要创建某种对象，但父类不该/不想知道具体类是谁（框架留扩展点的典型方式）。

●你希望通过继承覆写来扩展“产物类型”，让调用方不动、流程不动。

一些具体的场景：

●框架扩展点：工厂方法很常见于“框架规定流程、业务方覆写创建”的场景（你写子类接入框架）。

●Spring 的 FactoryBean：它的语义就是“这个 bean 不是普通 bean，而是用来生产另一个对象的”，并且暴露的是 getObject() 创建出来的对象。

●Java ServiceLoader：通过 SPI 在运行时发现/加载实现类，属于“把具体实现延迟到运行时配置/部署”的一类机制，和“解耦创建与使用”的目标一致。

注意模式的命名

我们回头看一下这个模式为什么叫 Factory Method，而不是干脆叫 Factory ? 这个命名是有讲究的。

核心原因在于：这个模式的灵魂是一个“方法”，而不是一个“类”。

1.“工厂 (Factory)”是一个通俗的广义概念：

在日常沟通中，只要一个类的主要职责是造对象，我们都叫它工厂（比如前面提过的“简单工厂”，它就是一个充斥着 if-else 的具体类）。

2.“工厂方法 (Factory Method)”强调的是面向对象中的“多态”与“继承”：

在 GoF 的定义中，创建对象的逻辑并不是封装在一个独立的、包揽大权的“工厂类”里，而是定义在了一个普通业务类（Creator）的内部，作为一个抽象方法存在。

●这个模式的精髓是：父类定义业务骨架，把其中“需要实例化具体对象”的那一步，挖空成一个方法（也就是 Factory Method）。

●具体的实例化工作，推迟（Defer）到了子类去重写这个方法来实现

一文讲透 GoF 的 23 种设计模式之单例

Wed, 25 Feb 2026 10:13:49 +0000

一文讲透 GoF 的 23 种设计模式之单例

单例模式–Singleton 是创建型模式

定义

确保一个类在一个 JVM 内只有一个实例，并提供全局访问点

什么时候用?

●配置中心、缓存管理器、日志器（有时）

●需要全局共享状态/资源

对于那些初始化很贵，重复创建又特别浪费资源的场景非常合适。

不要滥用

单例本质是“全局变量 + 访问入口”，会增加耦合、影响测试

实现方式

以下为常见的 5 种实现方式对比。

实现方式	核心机制简述	并发安全性 (线程安全)	性能表现	核心易错点 / 致命缺陷	综合推荐度
1. 饿汉式(Eager)	类加载时立即创建静态 final 实例。	安全(JVM类加载机制保证)	高 (运行时)获取实例无锁。但可能会拖慢系统启动速度，且如果不用会浪费内存。	低实现简单，不易出错。缺点是无法进行懒加载，且难以传递动态参数进行初始化。	⭐⭐⭐
2. 懒汉式(同步方法)	在 getInstance 方法上加 synchronized 锁。	安全(粗粒度锁保证)	非常低每次调用 getInstance 都要发生线程竞争和锁获取，高并发下是严重的性能瓶颈。	低实现简单。主要的"错"是选择了这种低效的方案。	⭐
3. 双重检查锁(DCL)	两次判空 + 同步代码块 + volatile 关键字。	安全 (有前提)必须在实例变量上加 volatile 禁止指令重排序。	高只在第一次初始化时加锁，后续调用无锁。实现了高性能的懒加载。	极高 (致命)最常见的错误是忘记加 volatile 关键字。这会导致多线程环境下，某个线程可能会拿到一个"半初始化"的对象，引发难以排查的 Bug。	⭐⭐⭐
4. 静态内部类(Holder模式)	利用 JVM 加载外部类时不加载静态内部类的特性实现懒加载。	安全(JVM类加载机制保证)	高既实现了懒加载，又在获取实例时没有任何锁机制，性能优异。	低非常规整的写法。唯一需要注意的是要确保构造函数私有，防止外部意外实例化。	⭐⭐⭐⭐⭐ (手动实现首选)
5. 枚举(Enum)	利用 Java 枚举类型的特殊语法和底层实现。	安全 (天然)(JVM 层面保障，防御反射和序列化攻击)	高类似于饿汉式，类加载时完成初始化，运行时无锁。	极低代码最简洁，几乎不可能写错。缺点是无法继承其他类，且在语义上用来做复杂业务对象时显得突兀。	⭐⭐⭐⭐⭐ (最安全简洁)

重点说明两种实现方式：枚举和静态内部类。

枚举

这是 Java 最简洁实现。Java 的 Enum 在语言层面有一些特殊保证（例如不会被克隆），这也是它常被用来实现单例的原因之一。

 1⚡ java片段public enum AppConfig {
 2 INSTANCE;
 3
 4 private String env = "prod";
 5
 6 public String getEnv() {
 7 return env;
 8 }
 9
10 public void setEnv(String env) {
11 this.env = env;
12 }
13
14 public static void main(String[] args) {
15 AppConfig c1 = AppConfig.INSTANCE;
16 AppConfig c2 = AppConfig.INSTANCE;
17
18 c1.setEnv("test");
19
20 System.out.println(c1 == c2); // true
21 System.out.println(c2.getEnv()); // test
22 }
23}

使用枚举（enum）来实现单例模式，被《Effective Java》的作者 Joshua Bloch 称为 “实现单例模式的最佳方法”。

它之所以备受推崇，是因为它用极其简洁的代码，完美解决了传统单例模式面临的线程安全、序列化破坏和反射破坏三大难题

原理一：利用 JVM 类加载机制保证“线程安全”

在传统的懒汉式单例中，为了保证多线程下只创建一个实例，我们需要写复杂的“双重检查锁（Double-Checked Locking）”并加上 volatile 关键字。

而枚举怎么做的？

当你定义 INSTANCE 时，编译器底层实际会把它转化为类似这样的代码：

⚡ java片段public static final AppConfig INSTANCE = new AppConfig();

Java 虚拟机（JVM）在加载类的时候，会利用底层的类加载机制保证静态成员的初始化是绝对线程安全的。在这个类被加载到内存时，JVM 会自动实例化 INSTANCE 且只实例化一次，整个过程由 JVM 内部加锁保证同步，不需要你手动写任何并发控制代码。

原理二：天生防御“反射攻击”

传统的单例模式有一个致命弱点：恶意代码可以通过 Java 的反射机制（Reflection）把私有构造函数设置为可见（setAccessible(true)），从而强行 new 出新的实例，打破单例。

而枚举怎么做的？

Java 的反射 API 从源码级别就直接“封杀”了通过反射创建枚举实例的可能性。如果你去看 Constructor.newInstance() 的 Java 底层源码，会发现有一段明确的校验逻辑：

1⚡ java片段if ((clazz.getModifiers() & Modifier.ENUM) != 0)
2 throw new IllegalArgumentException("Cannot reflectively create enum objects");

也就是说，一旦 JVM 发现你要用反射去创建枚举类的对象，就会直接抛出异常，从根本上杜绝了反射攻击。

原理三：天生防御“序列化破坏”

传统的单例对象如果实现了 Serializable 接口，在进行网络传输或持久化到磁盘再反序列化读取回来时，默认会重新分配内存，生成一个全新的对象。传统做法是必须手动写一个 readResolve() 方法来返回原实例。

而枚举怎么做的？

Java 规范对枚举的序列化有特殊的规定。枚举在序列化的时候，仅仅是将枚举常量的名称（name）输出到了结果中；在反序列化的时候，Java 会调用 java.lang.Enum.valueOf() 方法，通过名字去查找并返回内存中已经存在的那个常量对象。

因此，无论你反序列化多少次，拿到的永远是内存里的同一个 INSTANCE 对象。

总结来说：枚举单例的核心原理就是 直接利用 Java 语言底层的机制：

●用 JVM 类加载机制搞定了线程安全。

●用反射 API 的硬编码拦截搞定了反射破坏。

●用特殊的名称匹配机制搞定了序列化破坏。

在理论上，枚举单例确实是“最完美”的单例实现；但在实际的工程代码中，它的出场率确实不高。这并不是因为枚举本身有 bug，而是因为它在现代工程架构、面向对象设计理念以及测试友好度上，存在一些不可避免的局限性

具体来说，有以下几个核心原因：

1.现代框架（如 Spring）接管了单例的管理这是最根本的原因。在现代 Java 工程中（尤其是企业级开发），我们几乎不再手动编写任何单例模式了。我们广泛使用 Spring/Spring Boot 这样的依赖注入（DI）框架。在 Spring 中，你只需要在一个普通的类上加上 @Service、@Component 或 @Configuration 注解，Spring 容器（IoC Container）就会默认将其作为一个单例来管理。框架不仅帮你保证了单例，还能帮你自动注入其他依赖（如数据库连接、其他服务），这比用枚举手写单例要强大、灵活得多。

2.违反了“语义”和开发者的直觉代码不仅是给机器运行的，更是给人读的。枚举的本来语义：代表一组固定的常量集合（如星期、颜色、订单状态）。单例的语义：通常是一个拥有复杂业务逻辑的管理类（如 UserManager、DatabaseConnectionPool）。

如果把一个复杂的业务服务写成 enum，会让接手代码的其他开发者感到困惑，这违反了“最小惊讶原则（Principle of Least Astonishment）”。感觉就像是“为了用单例模式而强行用枚举”。

3.面向对象特性的缺失（无法继承） Java 规定，所有的枚举类都隐式继承了 java.lang.Enum。因为 Java 不支持多重继承，这意味着你的枚举单例不能再继承任何其他的父类。如果你的架构需要 AppConfig 继承一个 BaseConfig 类来复用代码，枚举单例直接就做不到。虽然枚举可以实现接口（implements Interface），但在需要共享基类代码的场景下，它的表现非常无力。

4.传参初始化非常困难在工程实践中，单例对象在初始化时往往需要外部参数。比如，一个数据库连接池单例，在启动时需要读取配置文件里的 url 和 password。普通的单例模式或 Spring 管理的 Bean，可以在运行时读取配置后，再进行初始化。枚举常量的实例化是在类加载的最早期进行的，这个时候你很难把运行时的参数优雅地传递给枚举的构造函数。

5.极难进行单元测试（Mock）在做单元测试时，我们经常需要把某些依赖的单例对象“Mock（模拟）”掉（比如使用 Mockito），以隔离测试环境。普通类别的单例很容易被 Mock 框架替换。但是，枚举是静态的全局常量，它的生命周期和类加载器绑定。在测试中强行替换枚举实例极其困难，容易导致测试用例之间互相污染。

在实际工程中：

●如果你要写一个完全无状态、不需要继承、不依赖外部配置的纯工具类/简单配置类，用枚举单例确实不错。

●但对于包含业务逻辑、需要依赖注入、需要被测试的类，交给 Spring 等框架去管理才是工业界的最佳实践。

静态内部类

如果你不想用枚举，又想要一个既能延迟加载（懒汉式），又绝对线程安全，还能完美避开繁琐的加锁（synchronized） 的单例，静态内部类是最佳选择。

 1⚡ java片段public class DatabaseConnectionPool {
 2
 3 // 1. 私有化构造函数，防止外部 new
 4 private DatabaseConnectionPool() {
 5 // 可选：在这里加上防御反射攻击的代码
 6 if (SingletonHolder.INSTANCE != null) {
 7 throw new RuntimeException("不允许通过反射创建单例！");
 8 }
 9 }
10
11 // 2. 核心：定义一个私有的静态内部类
12 // 这个类直到被调用时才会被 JVM 加载
13 private static class SingletonHolder {
14 // 由 JVM 保证这里的实例化是绝对线程安全的
15 private static final DatabaseConnectionPool INSTANCE = new DatabaseConnectionPool();
16 }
17
18 // 3. 提供全局访问点
19 public static DatabaseConnectionPool getInstance() {
20 // 只有在调用这里时，SingletonHolder 才会被加载，从而实例化 INSTANCE
21 return SingletonHolder.INSTANCE;
22 }
23}

为什么它很巧妙？

●懒加载（Lazy Loading）：当你加载 DatabaseConnectionPool 这个类时，内部类 SingletonHolder 并不会被立刻加载。只有当你真正调用 getInstance() 方法时，内部类才会被加载，对象才会被创建。这就节省了内存。

●零并发负担：它没有使用任何 synchronized 或者 volatile 关键字。它完全将线程安全的控制权交给了 JVM 底层的类加载机制（JVM 在加载一个类时，会自动加锁保证全局唯一）。

Spring 是如何实现单例的？

Spring 里的单例（Singleton）和我们在《设计模式》书里学到的单例，在概念和实现思路上有很大的不同。

●传统单例（GoF单例）：保证在一个 JVM（准确地说是类加载器）级别，某个类只有一个实例。类自己控制自己的实例化。

●Spring 单例：保证在一个 Spring IoC 容器（ApplicationContext）内部，某个指定的 Bean 名称只有一个实例。它是由 Spring 框架来统一管理的。

Spring 实现单例的核心原理可以概括为：单例注册表（Singleton Registry）

1. 核心数据结构：ConcurrentHashMap

如果你翻开 Spring 的底层源码（DefaultSingletonBeanRegistry 类），你会发现 Spring 管理单例的本质，就是一个大大的缓存 Map：

1⚡ java片段// Spring 源码中的 "一级缓存"，存放所有完全初始化好的单例 Bean
2private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

Spring 的单例其实就是把创建好的对象塞进了一个线程安全的 ConcurrentHashMap 里。Key 是 Bean 的名字（通常是类名首字母小写），Value 就是这个类的实例对象。

2. Spring 创建单例的流程

当你在代码里注入一个单例（比如通过 @Autowired），或者调用 context.getBean(“myService”) 时，Spring 大致会经历以下步骤：

1.查缓存：Spring 首先会去 singletonObjects 这个 Map 里查，看看有没有叫 “myService” 的对象。

2.有则返回：如果 Map 里有，说明已经创建过了，直接把这个对象返回给你。这就是单例的体现。

3.无则创建并加锁：如果 Map 里没有，Spring 就会准备创建它。为了保证在多线程环境下只有一个线程能去创建这个 Bean，Spring 会对这个 Bean 的名字进行加锁（通常是通过对全局单例集合的锁或者特定的互斥锁来实现同步）。

4.实例化与初始化：Spring 通过反射调用构造函数把对象 new 出来，然后进行属性填充（依赖注入），再调用 @PostConstruct 等初始化方法。

5.放入 Map 并返回：最后，把完全准备好的对象放进 singletonObjects 这个 ConcurrentHashMap 里，然后返回给你。以后所有对这个 Bean 的请求，都直接从 Map 里拿。

3. 补充：循环依赖的杀手锏“三级缓存”

Spring 在管理单例时，还要解决一个传统单例很难解决的问题——循环依赖（比如 A 依赖 B，B 又依赖 A）。

为了解决这个问题，Spring 其实并没有只用一个 Map，而是用了三个 Map（传说中的三级缓存）：

●一级缓存（singletonObjects）：存完整的、可用的单例对象。

●二级缓存（earlySingletonObjects）：存半成品对象（刚 new 出来，但还没注入属性的对象），用于提前暴露自己，打破循环。

●三级缓存（singletonFactories）：存对象工厂，用于在需要时生成代理对象（比如处理 AOP 切面）。

结合上面的图，核心过程如下：

第一阶段：A 的创建与曝光

1.调用 getBean(A)：Spring 容器开始创建 Bean A。

2.实例化 A：调用构造函数，A 对象在内存中诞生，但属性（如 B）还是 null。

3.暴露三级缓存：Spring 将 A 的工厂对象放入三级缓存 (singletonFactories)。这是解决循环依赖的关键一步，意味着此时如果有其他对象引用 A，可以通过这个工厂拿到 A 的引用。

第二阶段：A 填充属性，触发 B 的创建

4.填充属性 B：A 发现自己依赖 B，于是暂停自己，转而去创建 B。

第三阶段：B 的创建与获取 A

5.实例化 B：B 对象诞生，属性（如 A）还是 null。

6.暴露三级缓存：将 B 的工厂放入三级缓存。

7.填充属性 A：B 发现自己依赖 A，于是尝试去缓存找 A。

第四阶段：B 从缓存中找到 A (核心转折)

8.查找缓存：

●找一级缓存？没有（A 还没彻底完工）。

●找二级缓存？没有（还没人提取过 A 的早期引用）。

●找三级缓存？有了！

9.升级缓存：

●B 调用三级缓存中的工厂方法，拿到 A 的早期引用。

●重点：如果 A 配置了 AOP（比如事务管理），这个工厂会提前生成 A 的代理对象。

●将 A 的早期引用放入二级缓存 (earlySingletonObjects)，并从三级缓存移除。

10.B 完成：B 拿到了 A 的引用，完成属性填充和初始化，放入一级缓存。

第五阶段：A 完成

11.A 获取 B：B 已经创建好了，A 顺利拿到 B 的引用。

12.A 完成：A 完成属性填充和初始化，放入一级缓存。

美国最好的工作 TOP 10

Fri, 13 Oct 2023 14:13:40 +0000

最近的就业形式大家懂的都懂，拿我所在的 IT 行业来说，由于经济下行，岗位稀缺，导致内卷更加严重，这是大家都清楚的，尤其北京今年的就业市场，感觉是往年最差的了，相比上海、杭州这些城市今年北京的 IT 就业形势更加严峻。

虽然客观现实如此，但我想也不要绝望，尽自己最大努力，该干嘛干嘛，我们的美国同行也不容易，咱们来看一看美国的软件开发岗位情况：

可以看到最近这段时间也在下行，确实不怎么样，但还没到最低谷。要知道经济是有周期的体验到这个周期的低谷，就代表未来可能越来越好了。

有很多研发同行想着要换行，觉着这个行业红利期过去了，很多东西见顶了，自己的岁数也大了，这个行业对中年人不友好。这些问题在我国确实都多多少少存在，不过单就这个行业来说，相对的还是一个不错的行业。

无论薪资待遇、性价比，排除那些特殊单位，在整个大的充分竞争的就业市场上还是很不错的。我说这个话可能同行没有感觉，但那些准备转行或者已经有行动的朋友一定有同感。别的不说，你去各招聘网站看看其他职业给多少薪资，区别非常大。同样的学历、年龄、付出的劳动（无论是脑力还是体力）它的性价比如何？

我们来看一下美国统计的数据

这是 2023年最新的职业和就业数据

排名第一的是软件开发薪资中位数是：$120,730（每年）失业率是：1.2% 岗位数：370,600

排名第八的是 IT 经理

排名第九的是 Web 开发

前十名，有三个是跟软件研发相关的，可见 IT行业的工作还是不错的，这也是为什么很多人到国外要转码的原因。

这是2023年最新的数据，无独有偶，2015年的一份数据表明，架构师是美国认为当时最好的工作。

借此数据我们来看一看美国最好的工作 TOP 10 都是什么吧。

Top1 软件架构师

工资中位数：124,000美元最高工资：169,000美元 10年就业增长率：23%

就像建筑师设计房屋一样，软件架构师为新程序制定设计计划。这通常意味着领导一个由开发人员和工程师组成的团队，并确保所有部分组合在一起以构建功能齐全的软件。

优点：新问题不断出现，新技术不断出现，让每一天都变得不同，并保持对专业人员的需求。软件架构师 Christopher Felpel 说：“我每周至少会收到一两次新机会的通知。” “那里有很多工作要做，这并不令我感到惊讶。”

Top2 视频游戏设计师

工资中位数：79,900美元最高工资：115,000美元 10年就业增长率：19%

对于视频游戏设计师来说，这并不全是乐趣和游戏。就像电影导演一样，他们负责项目的整个创意愿景，并领导程序员、设计师和艺术家团队来实现愿景。

优点：这个行业相对较新，因此仍然是一个非常创新的领域。“定义一种新的表达媒介的机会每个世纪都会出现一两次，你必须成为其中的一部分，”视频游戏设计师沃伦·斯佩克特说。

Top3 土地管理者

工资中位数：103,000美元最高工资：160,000美元 10年就业增长率：13%

随着国家能源繁荣的展开，土地管理者需要在公司和拥有资源的人们之间谈判石油和天然气租赁。他们走遍乡村寻找愿意出售矿权的人，并为他们与石油公司牵线搭桥。尽管石油价格波动，但对石油行业及其行业前景的长期预测仍然强劲。

优点：这份工作最棒的事情之一就是将项目进行到底，这通常会让普通人获得可观的报酬。

Top4 专利代理人

工资中位数：126,000美元最高工资：182,000美元 10年就业增长率：13%

专利代理人审查发明并决定是否应为其申请专利，准备和提交专利申请，并在美国专利商标局代表发明人。

优点：接触新发明意味着可以接触到很多伟大的想法。“如果某件事不新鲜，我就不需要知道，”波士顿地区的专利代理人丹·贝纳特 (Dan Beinart) 说。“我从来不需要两次参与同一件事。”

Top5 医院管理员

工资中位数：114,000美元最高工资：207,000美元 10年就业增长率：23%

医院管理人员与不同部门和工作人员协调，以保持医院顺利运转。他们协调医疗专业人员、患者和操作人员的工作，以创造高效的运作。

优点：挑战每天都会出现，因此没有哪两天是相同的。“这是一个由不同事物组成的大网，归结为照顾病人的简单概念，” 医院管理员杰克·戈利奇 (Jake Golich) 说。

Top6 持续改进经理

工资中位数：96,600美元最高工资：130,000美元 10年就业增长率：12%

持续改进经理确定提高公司效率的目标，然后教员工如何实现这些目标，并审查这些实践在文化中的嵌入程度。这一切都是为了确保公司继续顺利前进。

优点：可实现的解决方案会在整个公司范围内产生巨大的影响，因此回报和影响力都是巨大的。雀巢饮用水公司的埃德·诺克 (Ed Noack) 表示：“最激励我的是，我每天都致力于帮助人们过上更好的生活。”

Top7 临床护理专家

工资中位数：89,300美元最高工资：130,000美元 10年就业增长率：19%

这些高级实践注册护士充当护士的临床资源，并与工作人员密切合作，处理复杂或高风险的患者。大多数人在医院工作，评估当前的方案并帮助实施新政策。他们主要致力于改善患者护理，并且可以专注于肿瘤学或疼痛管理等特定护理领域。

优点：制定最佳护理计划或创建新的全系统程序来改善护理是一项令人满意的工作福利。“你可以对许多患者的护理产生影响，工作人员会向你寻求支持和指导，”中枢神经系统医师乔安妮·菲利普斯 (JoAnne Phillips) 说。“没有什么比看到护士眼中闪烁的‘哦，现在我明白了’更好的了。”

Top8 数据库开发人员

工资中位数：88,200美元最高工资：126,000美元 10年就业增长率：23%

数据库开发人员就像数据管理员。他们的工作是确保公司能够访问他们从客户那里收集的数据，并想出办法将所有数据组织成有意义的东西。企业利用这些信息来提高效率和盈利能力。

优点：随着技术日新月异，有很多学习新事物的机会。“我喜欢我所做的事情，因为我基本上每天都面临着挑战，”数据库开发人员 Joanne Chan 说。“我现在做的90%的事情，三年前我都不知道。”

Top9 信息保障分析师

工资中位数：96,400美元最高工资：126,000美元 10年就业增长率：37%

我们的个人信息——从电子邮件到我们存储在“云”上的信息——比以往任何时候都更加明显地可能被暴露。信息保障分析师试图防止这种情况发生。他们决定如何让需要信息的人轻松获取信息，同时防止信息落入坏人之手。

优点：在隐私方面存在很多问题，因此这是一个 24/7 的问题。随着越来越多的公司考虑如何保持安全，需求也在不断增长。“对我来说，有趣的部分是解决一个没有正确答案的复杂问题，并努力解决它，”

Top10 普拉提/瑜伽教练

工资中位数：62,400美元最高工资：119,000美元 10年就业增长率：13%

瑜伽教练在教学课程之间平衡时间，将身体和精神结合在一起，计划每节课的内容并宣传工作室。

优点：对于许多瑜伽教练来说，能够改变一个人的一天或他们的生活方式，无论是身体上还是精神上，都是工作中最好的部分。瑜伽教练马克·尼尔森说：“对我来说，与人的联系是最好的部分，告诉他们生活中遇到挑战，现在他们在垫子上遇到挑战，让我们把他们聚集在一起。”

领域驱动设计：从学习到实践（一）

Thu, 16 Jul 2020 10:08:09 +0000

什么是领域驱动设计？

《**领域驱动设计 软件核心复杂性应对之道**》这本书是由 Eric Evans “领域驱动设计之父”，世界杰出软件建模专家所写。市面上绝大多数方法论资料的源头都是出自作者。**建议大家买来纸质书或电子书看看。**

 正如这本书的副标题所说，领域驱动设计就是为了解决软件的核心复杂性的。

回首过去

 在我以前的软件开发经验中，很多软件都是基于分层思想+贫血模式设计的（如下图）。我从入行就开始学习在MVC模式下进行编码开发。各种框架如strtus、mybatis、hibernate springMVC的应用也都基于此模式来进行。

 在多年的开发过程中，经历过

```
 用mybatis替换hibernate
```
```
 用springMVC替换struts
```

 业务逻辑重重的写在service层，因为太重又进行了多次重构

 再回顾下我们的研发流程：一般是从需求开始，产品同学将需求分析完和开发同学进行需求评审，评审完毕后开发同学开始基于需求进行设计，一般会落到数据库设计，将库表设计完毕后，再向上进行分层开发。如果是前后端分离的项目，会在前期约定接口，进行基于契约的并行开发。所以，**我们称这种方式为数据驱动开发，或基于数据模型的开发。**

 **![Image](003-2e8f3777.png "image.png") ![Image](004-94d15702.png "image.png")**

聊聊现在

 时代在发展，当年一个单体应用就是一个项目和软件，现在一个个的单体都被消灭了，大家也都转向了分布式和微服务。各种拆分、解耦，微服务大行其道，让计算机软件能够承载更多的需求，解决更大的问题。然而有利也有弊，比如：就算单体应用再大，对于一个新人而言，一个业务逻辑debug一趟也基本了解了。而在微服务架构下，一个服务的调用链可能连开发者自己都不一定能梳理清楚（一般要借助工具）。想把所有的逻辑完整的弄清楚是件很困难的事，系统越大越复杂越困难。即便在服务边界内由于代码并没有很清晰的业务概念和描述，也很难快速理解业务逻辑。你可能说这是新人，等新人成长了就好了。（呵呵，新人的体验差真的不解决一下吗？）老人就没有问题吗？当业务逻辑越来越复杂，代码越来越腐败，文档没人维护，留给你的也基本算是一滩沼泽了。我有过这种经历，那种想重新写个新服务的想法特别强烈。

 总结来说，我们在新时代拥抱了微服务和分布式解决了很多扩展性上的问题，然后并没有解决软件复杂性的问题，具体来说有:

代码没体现业务，光看代码不能支撑你理解业务
业务知识没有沉淀下来，对于业务的理解只能找业务专家和技术老人拼图（产品文档更新不及时，最终还是要看代码）
软件工程师沦为CURD工程师（何时能走上业务专家的路？）
系统逐渐走向复杂和庞大，对系统的修改由于太过复杂和不甚了解而变得战战兢兢。
代码腐败，扩展性差、迭代困难（从立项到重写）

展望未来

 幸运的是，我们并不是第一个遇到这种问题的人，在经历了大量类似场景后，前人们归纳总结了解决问题的办法，更幸运的是它与我们流行的微服务、分布式理论又是那么的契合。**这就是领域驱动设计。**

 观察上图，战略和战术设计是站在DDD的角度进行划分。战略设计侧重于高层次、宏观上去划分和集成限界上下文，而战术设计则关注更具体使用建模工具来细化上下文。

 **DDD战略设计产生的领域模型可以作为微服务设计的输入。此时，DDD的战术设计又恰好可以与微服务的设计完美无缝结合。**

（上面这两段话懂的就懂了，不懂的，我们在后文还会再继续阐述，结合前面的知识你一定能明白。）

统一的语言

 **这是领域驱动设计的第一步，也是非常重要的一步，好的开始是成功的一半。**

 开发团队与领域专家针对具体问题域与业务期望进行沟通，那么沟通要有统一的语言，不然产品有产品的术语，技术有技术的术语，业务还有业务的术语，大家鸡同鸭讲如何能把事儿说清楚？当然主要还是要依赖于业务，将业务术语和逻辑搞明白了，大家有统一而清晰的认识。（刚开始可能不明白，需要多与业务沟通，了解清楚，从源头就搞错了就尴尬了）。

 这是一个将业务领域知识转化的过程，这里最熟悉业务的当然是领域专业或者业务专家，然而我们不是完全把他们所说的原封不动地copy下来，我们是要基于这些业务，用我们的技术知识、产品知识做出可用的软件来，最终它是个软件，我们把这些知识结合在一起，产出一个既满足业务逻辑又是合理的模型抽象。所有甚至有时候技术人员要让领域专家理解技术的解决方法。这样进行反复的沟通才能最终生出好的**领域模型**。这是建模的过程。

 有了统一的认识如何落地？具体来说就是我们要落到纸面上，以便所有相关人员的理解，后面的开发、沟通都要基于这个。一般我们会用画图的方式，当然也可以结合一些文档说明。这就是统一的语言，将模型用统一的语言（图、文档）描述出来。所有人对业务的理解都是一致统一的。

模型，这种知识形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义，并专注于问题。

 那有没有可用的工具和方法？还真有。（domain story telling ）

 方法：domain story telling

 网站：https://domainstorytelling.org/

 建模工具：https://github.com/WPS/domain-story-modeler

最终画出的图类似这样：

 domain story telling 只有四类元素来表达领域模型

 **![Image](008-a4951963.png "image.png")**

 **actor’s 演员，可以是人、团体或软件系统**

 **work objects 操作的对象，比如文档、消息等**

```
 **activities 动作**
```

 **annotations 注释**

**利用统一的语言最终产出的就是最初的领域概念模型（后面实践篇，我们会看些具体例子）**

接下来我们会对这个模型进行领域分析和考虑划分领域，找到领域边界。

未完待续……

关注公众号获取更多精彩内容

一个学习设计模式的好资源

Mon, 06 Apr 2020 04:15:27 +0000

https://refactoringguru.cn/design-patterns

上面是网站地址，不说别的，光是图画的就深得我心。

贴几个大家感受下：

工厂方法模式是一种创建型设计模式，其在父类中提供一个创建对象的接口，允许子类决定实例化对象的类型。

抽象工厂模式是一种创建型设计模式，它能创建一系列相关的对象，而无需指定其具体类。

生成器模式是一种创建型设计模式，使你能够分步骤创建复杂对象。该模式允许你使用相同的创建代码生成不同类型和形式的对象。

原型模式是一种创建型设计模式，使你能够复制已有对象，而又无需使代码依赖它们所属的类。

单例模式是一种创建型设计模式，让你能够保证一个类只有一个实例，并提供一个访问该实例的全局节点。

适配器模式是一种结构型设计模式，它能使接口不兼容的对象能够相互合作。

怎么样？还不错吧，有些模式光看图你就大概明白是怎么回事儿了。网站上也有它的电子书卖（注意，这不是广告，我也没拿钱啊）。想买书的也可以买本来看看，不过我觉得看网站上的大部分内容应该就够了。

关注公众号获取更多精彩内容

一个实例搞懂抽象工厂模式

Sun, 15 Mar 2020 16:00:00 +0000

关于工厂模式三兄弟（简单工厂、工厂方法、抽象工厂），前两个兄弟比较容易懂，基本一看就明白，第三位兄弟初看起来确实有些抽象，网上看到一个例子讲的很好，分享给大家，保证一看就明白。

文末给出系列文章出处。

Sunny软件公司欲开发一套界面皮肤库，可以对Java桌面软件进行界面美化。为了保护版权，该皮肤库源代码不打算公开，而只向用户提供已打包为jar文件的class字节码文件。用户在使用时可以通过菜单来选择皮肤，不同的皮肤将提供视觉效果不同的按钮、文本框、组合框等界面元素，其结构示意图如图所示：

图1 界面皮肤库结构示意图

该皮肤库需要具备良好的灵活性和可扩展性，用户可以自由选择不同的皮肤，开发人员可以在不修改既有代码的基础上增加新的皮肤。

Sunny软件公司的开发人员针对上述要求，决定使用工厂方法模式进行系统的设计，为了保证系统的灵活性和可扩展性，提供一系列具体工厂来创建按钮、文本框、组合框等界面元素，客户端针对抽象工厂编程，初始结构如图所示：

图2 基于工厂方法模式的界面皮肤库初始结构图

在图2中，提供了大量工厂来创建具体的界面组件，可以通过配置文件更换具体界面组件从而改变界面风格。但是，此设计方案存在如下问题：

(1) 当需要增加新的皮肤时，虽然不要修改现有代码，但是需要增加大量类，针对每一个新增具体组件都需要增加一个具体工厂，类的个数成对增加，这无疑会导致系统越来越庞大，增加系统的维护成本和运行开销；

(2) 由于同一种风格的具体界面组件通常要一起显示，因此需要为每个组件都选择一个具体工厂，用户在使用时必须逐个进行设置，如果某个具体工厂选择失误将会导致界面显示混乱，虽然我们可以适当增加一些约束语句，但客户端代码和配置文件都较为复杂。

如何减少系统中类的个数并保证客户端每次始终只使用某一种风格的具体界面组件？这是Sunny公司开发人员所面临的两个问题，显然，工厂方法模式无法解决这两个问题，别着急，本文所介绍的抽象工厂模式可以让这些问题迎刃而解。

Sunny公司开发人员使用抽象工厂模式来重构界面皮肤库的设计，其基本结构如图所示：

如果需要更换皮肤，只需修改配置文件即可，在实际环境中，我们可以提供可视化界面，例如菜单或者窗口来修改配置文件，用户无须直接修改配置文件。如果需要增加新的皮肤，只需增加一族新的具体组件并对应提供一个新的具体工厂，修改配置文件即可使用新的皮肤，原有代码无须修改，符合“开闭原则”。

扩展

在真实项目开发中，我们通常会为配置文件提供一个可视化的编辑界面，类似Struts框架中的struts.xml编辑器，大家可以自行开发一个简单的图形化工具来修改配置文件，实现真正的纯界面操作。

本文并没有展开讲抽象工厂模式的方方面面，只是用一个例子，让大家对这个设计模式有个直观的感受，让它“落地”到实例中，建议大家看看下面的系列文章（认真看用不了多久），我也是从这里摘取的例子。

以下为文章参考出处: 《工厂三兄弟之抽象工厂模式》

关注公众号获取更多精彩内容

设计模式没时间学？(一图带你搞定23种设计模式)

Sat, 14 Mar 2020 16:00:00 +0000

**设计模式学完容易忘? **

**设计新东西时，不知道用哪个？ **

知道用哪个模式又开始手忙脚乱的一通查？

面试让画个设计模式的UML图拉了胯？

你碰到的问题很多人都有

早在2007年国外的Jason McDonald小哥就为我们整理出了一个超精简版设计模式文件（文末有下载链接，大家可以去下载原PDF文件）

所谓精简版，既没有详细地论证和介绍每一个模式，而是让在你有一定理论基础的情况下，通过这个文件快速回顾或回忆起来。如果你对每一种设计模式还不清楚，建议还是先认认真真学习一遍（比如看四人帮写的相关书籍），不然看了也不深刻。

设计模式分类

这23种设计模式，可以分为三类，如下图所示

架构与方法 on 小盒子的技术分享

一文讲透 GoF 的 23 种设计模式之工厂方法

一文讲透 GoF 的 23 种设计模式之工厂方法

定义

简单工厂

第一步：定义产品的共同接口和具体实现

第二步：创建“简单工厂”类

第三步：客户端调用

工厂方法模式的结构与角色

Java 代码实现

1. 定义产品（大模型客户端）

2. 定义创建者（核心：业务骨架 + 工厂方法）

3. 定义具体创建者（子类重写工厂方法）

4. 客户端调用

什么时候用?

注意模式的命名

一文讲透 GoF 的 23 种设计模式之单例

一文讲透 GoF 的 23 种设计模式之单例

定义

什么时候用?

不要滥用

实现方式

枚举

静态内部类

Spring 是如何实现单例的？

1. 核心数据结构：ConcurrentHashMap

2. Spring 创建单例的流程

3. 补充：循环依赖的杀手锏“三级缓存”

美国最好的工作 TOP 10

Top1 软件架构师

Top2 视频游戏设计师

Top3 土地管理者

Top4 专利代理人

Top5 医院管理员

Top6 持续改进经理

Top7 临床护理专家

Top8 数据库开发人员

Top9 信息保障分析师

Top10 普拉提/瑜伽教练

领域驱动设计：从学习到实践（一）

什么是领域驱动设计？

回首过去

聊聊现在

展望未来

统一的语言

一个学习设计模式的好资源

一个实例搞懂抽象工厂模式

以下为文章参考出处: 《工厂三兄弟之抽象工厂模式》

设计模式没时间学？(一图带你搞定23种设计模式)

设计模式分类

责任链模式

命令模式

解释器模式

迭代器模式

中介者模式

备忘录模式

观察者模式

状态模式

策略模式

模版模式

访问者模式

适配器模式

桥接模式

组合模式

装饰器模式

门面模式

享元模式

代理模式

抽象工厂模式

构造器模式

工厂方法模式

原型模式

单例模式