clojure 的协议本质上是开放的，不支持 java 式的“密封接口”机制；但可通过词法作用域、私有协议与显式工厂函数组合，实现逻辑上的受控多态——即仅允许预定义的少数类型参与协议实现。
clojure 的协议本质上是开放的，不支持 java 式的“密封接口”机制；但可通过词法作用域、私有协议与显式工厂函数组合，实现逻辑上的受控多态——即仅允许预定义的少数类型参与协议实现。
Clojure 的协议（defprotocol）设计初衷是解决表达问题（Expression Problem）：允许在不修改现有代码的前提下，为已有数据类型添加新行为，或为新类型添加已有行为。这天然要求协议具备运行时可扩展性——任何命名空间均可调用 extend-type 或 extend-protocol 为其关心的类型实现协议。因此，Clojure 不提供、也不计划引入语法级的“密封协议”机制（如 Java 17+ 的 sealed interface），因为这与动态性、组合性及 REPL 驱动开发哲学相悖。
但这并不意味着无法实现“受控多态”。关键在于将协议的定义、实现与使用进行封装，通过设计约束替代语言强制：
✅ 推荐实践：词法封装 + 私有协议 + 显式构造器
以下是一个典型模式示例，模拟“仅允许 Circle 和 Rectangle 实现 Shape 协议”：
(ns shape-system.core
(:require [clojure.spec.alpha :as s]))
;; 1. 定义私有协议（仅本命名空间可见）
(defprotocol ^:private ShapeProtocol
(area [this])
(perimeter [this]))
;; 2. 定义具体记录类型（公有）
(defrecord Circle [radius]
ShapeProtocol
(area [_] (* Math/PI radius radius))
(perimeter [_] (* 2 Math/PI radius)))
(defrecord Rectangle [width height]
ShapeProtocol
(area [_] (* width height))
(perimeter [_] (* 2 (+ width height))))
;; 3. 提供受控构造函数（唯一合法创建途径）
(defn make-circle [r] (->Circle r))
(defn make-rectangle [w h] (->Rectangle w h))
;; 4. 提供统一操作函数（接受任意 ShapeProtocol 实现）
(defn describe [shape]
{:area (area shape)
:perimeter (perimeter shape)})
;; ✅ 安全使用示例
(describe (make-circle 5)) ; => {:area 78.5398..., :perimeter 31.4159...}
(describe (make-rectangle 3 4)) ; => {:area 12, :perimeter 14}
;; ❌ 无法外部扩展：以下代码在其他命名空间中无效（因 ShapeProtocol 是私有的）
;; (extend-type java.lang.String ShapeProtocol ...) ; 编译失败：Unable to resolve symbol: ShapeProtocol
⚠️ 注意事项与权衡
- 无编译期检查：Clojure 不会在编译时阻止非法 extend-* 调用（若协议非私有），因此私有协议 + 命名空间隔离是逻辑封禁的核心；
- 工具链友好性：配合 clojure.spec 可进一步约束函数输入（如 (s/fdef describe :args (s/cat :shape ::shape))），提升文档性与测试覆盖率；
- 与 defrecord/deftype 绑定更安全：相比动态 extend-type，直接在记录定义中实现协议，能确保类型与行为的一致性；
- 避免过度设计：若业务确实需要强封装与封闭变体（如状态机、AST 节点），应优先考虑 defrecord + 多方法（defmulti/defmethod）并配合 :dispatch 函数控制分发范围，而非强行模拟密封接口。
✅ 总结
Clojure 不支持、也不鼓励 Java 式的密封协议——这不是缺陷，而是对动态性与组合优先原则的坚守。真正的“受控多态”在 Clojure 中体现为：通过模块化封装、私有边界与约定优于配置的设计，将扩展点显式收口，使协议的使用成为受信契约，而非开放沙盒。开发者应拥抱这一范式，而非移植静态语言的约束模型。
