模式不是套路（一）：Rust 让设计模式返璞归真

public class Singleton {
    private static volatile Singleton instance;
    private static final Object lock = new Object();

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (lock) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

use std::sync::OnceLock;

static CONFIG: OnceLock<Config> = OnceLock::new();

fn get_config() -> &'static Config {
    CONFIG.get_or_init(|| Config::load())
}

错误的学法：
  1. 背诵 23 种模式的名字和结构
  2. 背诵每种模式的 UML 图
  3. 背诵每种模式的"标准实现"
  4. 面试时默写出来

正确的学法：
  1. 理解每种模式要解决什么问题
  2. 理解模式背后的设计原则
  3. 在实际场景中识别问题
  4. 用合适的方式解决，不拘泥于形式

不用模式语言："我们需要一个东西，能够根据不同的情况创建不同类型的对象，
              而且调用方不需要知道具体创建了什么类型。"

用模式语言："这里需要一个工厂。"

1990 年代主流语言的特点：
  - 面向对象（类、继承、多态）
  - 手动内存管理或 GC
  - 没有泛型（或很弱）
  - 没有 trait/interface 的 default 实现
  - 没有 algebraic data types

// 定义策略接口
interface PricingStrategy {
    double calculatePrice(double basePrice);
}

// 具体策略：正常价格
class NormalPricing implements PricingStrategy {
    public double calculatePrice(double basePrice) {
        return basePrice;
    }
}

// 具体策略：VIP 折扣
class VipPricing implements PricingStrategy {
    public double calculatePrice(double basePrice) {
        return basePrice * 0.8;
    }
}

// 使用策略
class Order {
    private PricingStrategy pricing;

    public void setPricing(PricingStrategy pricing) {
        this.pricing = pricing;
    }

    public double getPrice(double basePrice) {
        return pricing.calculatePrice(basePrice);
    }
}

trait PricingStrategy {
    fn calculate_price(&self, base_price: f64) -> f64;
}

struct NormalPricing;
impl PricingStrategy for NormalPricing {
    fn calculate_price(&self, base_price: f64) -> f64 {
        base_price
    }
}

struct VipPricing {
    rate: f64, // 折扣率，0.8 表示八折
}

impl VipPricing {
    fn new(rate: f64) -> Self {
        Self { rate }
    }
}

impl PricingStrategy for VipPricing {
    fn calculate_price(&self, base_price: f64) -> f64 {
        base_price * self.rate
    }
}

struct Order {
    pricing: Box<dyn PricingStrategy>,
}

impl Order {
    fn new(pricing: Box<dyn PricingStrategy>) -> Self {
        Self { pricing }
    }

    fn get_price(&self, base_price: f64) -> f64 {
        self.pricing.calculate_price(base_price)
    }
}

struct Order<P: PricingStrategy> {
    pricing: P,
}

impl<P: PricingStrategy> Order<P> {
    fn new(pricing: P) -> Self {
        Self { pricing }
    }

    fn get_price(&self, base_price: f64) -> f64 {
        self.pricing.calculate_price(base_price)
    }
}

// 编译时确定具体类型，零运行时开销
let order = Order::new(VipPricing::new(0.8));

struct Order {
    pricing: Box<dyn Fn(f64) -> f64>,
}

impl Order {
    fn new(pricing: impl Fn(f64) -> f64 + 'static) -> Self {
        Self { pricing: Box::new(pricing) }
    }

    fn get_price(&self, base_price: f64) -> f64 {
        (self.pricing)(base_price)
    }
}

// 使用闭包作为策略
let normal_order = Order::new(|price| price);
let vip_order = Order::new(|price| price * 0.8);
let special_order = Order::new(|price| if price > 100.0 { price * 0.7 } else { price * 0.9 });

第二篇：配置系统——从硬编码到热加载
  ├── 单例模式：全局配置如何安全共享
  ├── 建造者模式：复杂配置对象的构建
  └── 原型模式：配置的深拷贝与继承

第三篇：插件架构——让系统长出翅膀
  ├── 工厂方法：插件的注册与创建
  ├── 抽象工厂：插件家族的管理
  └── 桥接模式：抽象与实现的分离

第四篇：数据管道——像乐高一样组装逻辑
  ├── 装饰器模式：给数据处理加 buff
  ├── 责任链模式：请求的流水线处理
  └── 策略模式：可插拔的处理算法

第五篇：状态流转——订单不只是 CRUD
  ├── 状态模式：状态机的优雅实现
  ├── 命令模式：操作的封装与撤销
  └── 备忘录模式：状态的快照与恢复

第六篇：事件驱动——模块间的优雅对话
  ├── 观察者模式：发布订阅的本质
  └── 中介者模式：解耦复杂的交互

第七篇：外部集成——与第三方和平共处
  ├── 适配器模式：接口的转换
  ├── 外观模式：复杂子系统的简化
  └── 代理模式：访问的控制与增强

第八篇：框架设计——把控制权还给用户
  ├── 模板方法：定义算法骨架
  └── 钩子模式：可选的扩展点

第九篇：树形世界——递归结构的驯服术
  ├── 组合模式：统一处理树形结构
  ├── 访问者模式：分离数据与操作
  ├── 迭代器模式：遍历的抽象
  └── 享元模式：共享细粒度对象

第十篇：规则引擎——让业务人员写代码
  ├── 解释器模式：DSL 的实现
  └── 策略模式的进阶：规则的动态组合

第十一篇：终篇——反模式与断舍离
  ├── 过度设计的症状
  ├── 模式的滥用案例
  └── 什么时候不需要模式

传统问题：
  - 单例：谁负责销毁？
  - 观察者：被观察者销毁时，如何通知观察者？
  - 命令：命令对象的生命周期如何管理？

// 所有权转移，不需要手动管理
fn process(command: Box<dyn Command>) {
    command.execute();
    // command 在这里自动释放
}

// Arc + Weak 解决观察者的引用循环
struct Subject {
    observers: Vec<Weak<dyn Observer>>,
}

// 状态模式：用 enum 替代继承体系
enum OrderState {
    Created { created_at: DateTime<Utc> },
    Paid { paid_at: DateTime<Utc>, amount: Decimal },
    Shipped { shipped_at: DateTime<Utc>, tracking: String },
    Delivered { delivered_at: DateTime<Utc> },
    Cancelled { reason: String },
}

impl OrderState {
    fn can_cancel(&self) -> bool {
        matches!(self, OrderState::Created { .. } | OrderState::Paid { .. })
    }

    fn next_actions(&self) -> Vec<&'static str> {
        match self {
            OrderState::Created { .. } => vec!["pay", "cancel"],
            OrderState::Paid { .. } => vec!["ship", "cancel"],
            OrderState::Shipped { .. } => vec!["deliver"],
            OrderState::Delivered { .. } => vec!["return"],
            OrderState::Cancelled { .. } => vec![],
        }
    }
}

// 可以为已有类型实现 trait（孤儿规则限制下）
impl MyTrait for Vec<String> {
    // 你的实现
}

// 可以有默认实现
trait Handler {
    fn handle(&self, request: &Request) -> Response;

    fn can_handle(&self, request: &Request) -> bool {
        true // 默认实现
    }
}

// 可以有关联类型
trait Iterator {
    type Item;
    fn next(&mut self) -> Option<Self::Item>;
}

// 可以组合多个 trait
fn process(item: impl Read + Write + Seek) {
    // 同时要求多种能力
}

错误的思路：
  "这里应该用什么设计模式？"

正确的思路：
  "这里的问题是什么？有什么解法？"
  "这个解法和某个模式很像，可以借鉴它的经验。"