引言

访问修饰符，在任何一门现代编程语言中，都是构建坚实、可维护代码的基石。它们如同建筑的“承重墙”与“门窗”，精确地定义了代码世界的边界与交互规则。在仓颉这门新兴的、面向未来的编程语言中，访问修饰符的设计更是体现了其对安全性、模块化和工程化的深刻理解。

本文将带你穿透语法表象，直达仓颉访问修饰符的设计内核，并结合有深度的实战代码，展示如何在复杂项目中优雅地运用它们。

1. 核心设计理念：默认安全与显式开放

与其他一些语言（如Java）不同，仓颉在设计上可能更倾向于“默认安全”原则。这意味着，如果你不显式声明，成员的可见性将被限制在最小的必要范围内。这种设计哲学极大地降低了因无意暴露内部实现而导致的代码耦合与脆弱性。

• private: 真正的“私有”，仅在当前定义的文件或作用域内可见。这是最严格的保护，确保实现细节被完美封装。

• internal: “内部的”，在同一模块（Module/Package）内可见。这是仓颉实现模块化设计的核心。它鼓励开发者将一个功能内聚的模块作为一个整体来思考，模块内部充分信任，对外则严格控制接口。

• public: “公开的”，对任何模块都可见。这是你希望暴露给外部世界、构成稳定API的部分。滥用public是大型项目腐化的开始，因此每一次使用都需要深思熟虑。

这种由内而外的“层级”设计，引导我们写出高内聚、低耦合的优质代码。👍

2. 深度实践：internal 的战略价值

在许多项目中，开发者往往只在 private 和 public 之间做选择，而忽略了 internal 的巨大潜力。internal 才是构建大型、可维护系统的关键所在。

场景：构建一个复杂的数据处理引擎

假设我们正在构建一个数据处理引擎模块（DataEngine），它包含数据加载（Loader）、数据转换（Transformer）和数据缓存（Cache）等多个组件che`）等多个组件。

反面教材（滥用 public）：

// --- Module: DataEngine ---

// 文件: Loader.ts
public class Loader {
    public func loadRawData(from source: String) -> RawData {
        // ... 实现细节 ...
        return RawData()
    }
}

// 文件: Transformer.ts
public class Transformer {
    public func cleanData(data: RawData) -> CleanData {
        // ... 实现细节 ...
        return CleanData()
    }
}

// 文件: DataEngine.ts
public class DataEngine {
    private let loader = Loader()
    private let transformer = Transformer()

    public func process(source: String) -> CleanData {
        let raw = loader.loadRawData(from: source)
        let clean = transformer.cleanData(data: raw)
        return clean
    }
}

在这个例子中，Loader 和 Transformer 都被标记为 public。这意味着，任何使用 DataEngine 模块的外部代码，都可以绕过 DataEngine 的主入口，直接实例化和调用 Loader。这破坏了引擎的整体封装，使得未来的重构（比如想替换 Loader 的实现）变得异常困难和危险。😱

最佳实践（善用 internal）：

// --- Module: DataEngine ---

// 文件: Loader.ts
internal class Loader { // 模块内部可见
    internal func loadRawData(from source: String) -> RawData {
        // 复杂的加载逻辑，例如处理网络、文件IO等
        console.log("内部加载器工作...")
        return RawData()
    }
}

// 文件: Transformer.ts
internal class Transformer { // 模块内部可见
    internal func cleanData(data: RawData) -> CleanData {
        // 核心转换算法
        console.log("内部转换器工作...")
        return CleanData()
    }
}

// 文件: DataEngine.ts
public class DataEngine { // 对外的唯一公共入口
    private let loader = Loader()
    private let transformer = Transformer()

    // 公开的API，定义了稳定的服务契约
    public func process(source: String) -> CleanData {
        console.log("数据处理引擎启动...")
        let raw = loader.loadRawData(from: source)
        let clean = transformer.cleanData(data: raw)
        console.log("数据处理完成！")
        return clean
    }
}

// --- Module: App (外部调用者) ---
// import { DataEngine } from "DataEngine"

// let engine = new DataEngine()
// engine.process("my_data_source.json")

// 下面的代码将无法编译，因为 Loader 是 internal 的
// import { Loader } from "DataEngine" // 错误！
// let unauthorizedLoader = new Loader()  // 错误！

思考与升华：

通过将 Loader 和 Transformer 标记为 internal，我们传达了一个清晰的架构意图：

1. **清晰界**：DataEngine 类是这个模块提供给外部世界的唯一“门面”（Facade）。所有交互都必须通过这个可控的、经过深思熟虑设计的API进行。

2. 内部实现的自由：我们可以在模块内部自由地重构 Loader 和 `Transformer，甚至将它们合并、拆分，只要不改变 DataEngine 的 public 接口，就不会对外部调用者产生任何影响。这在大型项目的长期演进中至关重要。

3. 降低认知负担：模块的使用者只需要关心 DataEngine 的 public 方法即可，无需理解其背后复杂的组件交互，大大降低了学习和使用成本。

3. 结语：超越语法，回归匠心

仓颉的访问修饰符，不仅仅是语法规则，更是其设计哲学的体现。它鼓励我们像一位“软件工匠”一样，精心雕琢代码的边界与接口。

• 用 private 守护好最小单元的纯粹。

• 用 internal 构建起模块化大厦的坚固城墙。

• 用 public 架设起连接世界、稳定可靠的桥梁。