clojure 的协议（protocol）天生是开放的，不支持 java 风格的“密封接口”机制；但可通过词法作用域、私有协议与受限构造函数，实现逻辑上受控的 ad-hoc 多态——即仅允许预定义类型实现该协议，从而兼顾灵活性与封装性。
clojure 的协议（protocol）天生是开放的，不支持 java 风格的“密封接口”机制；但可通过词法作用域、私有协议与受限构造函数，实现逻辑上受控的 ad-hoc 多态——即仅允许预定义类型实现该协议，从而兼顾灵活性与封装性。
Clojure 的协议设计哲学与 Java 截然不同：它旨在解决表达式问题（Expression Problem），核心诉求是在不修改现有代码的前提下，为已有数据类型添加新行为，或为新类型添加已有行为。因此，协议必须保持开放——任何命名空间均可随时通过 extend-type 或 extend-protocol 为任意类型扩展协议实现。这种动态性正是 Clojure 作为动态语言的表达力所在，但也意味着原生不提供类似 Java sealed interface 或 Kotlin sealed class 的编译期强制约束。
但这并不等于无法实现“受控多态”。关键在于转变思路：不依赖语言级密封，而通过模块化设计与封装边界达成逻辑密封。典型做法是：
- 将协议定义为 private（使用 defprotocol + ^:private 元数据或置于 defn- 同级作用域）；
- 在同一个命名空间内，仅通过受控的构造函数（如 ->Foo、create-bar）生成已知类型；
- 这些类型在定义时就完成协议扩展（extend-type），且不暴露扩展能力给外部；
- 对外仅暴露协议函数和构造函数，隐藏协议本身及扩展机制。
以下是一个完整示例，模拟“仅允许 Circle 和 Rectangle 实现 Shape 协议”的语义：
(ns shape.core
(:require [clojure.spec.alpha :as s]))
;; 私有协议 —— 不被其他 ns 引用，不支持外部 extend
(def ^:private Shape
(defprotocol ^:private Shape
(area [this])
(perimeter [this])))
;; 内部实现：仅 Circle 和 Rectangle 被允许且已实现
(defrecord Circle [radius]
Shape
(area [_] (* Math/PI radius radius))
(perimeter [_] (* 2 Math/PI radius)))
(defrecord Rectangle [width height]
Shape
(area [_] (* width height))
(perimeter [_] (* 2 (+ width height))))
;; 受控构造函数 —— 唯一创建合法实例的入口
(defn ->circle [r] (->Circle r))
(defn ->rectangle [w h] (->Rectangle w h))
;; 对外暴露的协议函数（自动 dispatch）
(defn area [x] (area x))
(defn perimeter [x] (perimeter x))
;; （可选）spec 约束输入类型，增强文档与运行时检查
(s/def ::shape (s/or :circle #?(:clj circle.Circle :cljs circle.Circle)
:rect #?(:clj rectangle.Rectangle :cljs rectangle.Rectangle)))
✅ 效果说明：
- 其他命名空间无法 require 或 refer Shape 协议；
- 无法对 String、Long 等类型调用 extend-type 实现 Shape（因协议不可见）；
- 用户只能通过 ->circle / ->rectangle 创建实例，并安全调用 area / perimeter；
- 若尝试 (extend-type java.lang.String Shape ...) 将抛出 ClassNotFoundException 或 IllegalArgumentException（因协议未解析）。
⚠️ 注意事项：
- 这种“逻辑密封”依赖开发者自律与模块边界，无法阻止反射或 eval 绕过（但 Clojure 生产环境极少滥用此类手段）；
- 若需更强保障，可结合 clojure.spec 定义输入契约，或在构建期通过自定义 lint 规则（如 eastwood + 自定义检查器）拦截非法 extend-* 调用；
- 对于需要绝对封闭性的领域模型（如金融核心类型），更推荐用 defrecord + 协议组合 + 构造函数校验，辅以文档与团队约定。
总结而言：Clojure 不提供、也不鼓励“密封协议”，因其违背动态扩展的设计初衷；但通过私有化协议、封装构造、明确接口边界，完全可以在实践中达成安全、可维护、可演进的受控多态——这恰是 Clojure “简单性优于完整性”哲学的体现：不靠语法糖封死可能性，而用组合与约定引导良好实践。
