类访问控制：readonly访问控制器是否可行，有何作用与副作用？

readonly访问控制符的常见副作用 #

这类允许外部读、仅内部可写的访问控制确实能简化简单状态属性的访问代码，但实际使用时会带来以下隐性问题：

• 破坏封装的实现隐蔽性
  直接暴露可读属性意味着外部代码会直接依赖该属性的类型、命名、存储逻辑。以你示例中的visited为例，如果后续业务迭代需要把布尔类型的访问状态扩展为三值枚举（未访问/访问中/已访问），所有直接读取visited属性的代码都要同步修改。如果是通过isVisited()方法访问，你只需要修改方法内部的判断逻辑，外部调用侧完全感知不到变更，维护成本低很多。
• 无法附加额外的访问逻辑
  公开只读属性本质是直接暴露存储字段，你没有办法在读取行为发生时插入额外逻辑：比如需要统计visited的读取次数、延迟计算visited的值（不需要一直存储，读的时候实时计算关联属性得到状态）、并发场景下加锁/加内存屏障保证读取的线程安全性，这些需求在暴露字段的场景下都无法实现，换成getter方法只需要修改方法内部逻辑即可，不会影响调用侧。
• 多态场景下能力受限
  如果你的基类Node存在子类，子类需要修改visited的判断逻辑（比如子类的节点状态还要关联父节点的访问状态），暴露只读字段的话完全无法实现这类自定义逻辑，而虚函数实现的isVisited()可以轻松被子类重写，调用侧不需要做任何调整。
• 存在被暴力修改的安全风险
  以C++为例，如果没有原生的readonly语法支持，很多开发者会通过公开const引用的方式模拟只读效果：

  class Node {
  private:
      bool _visited;
  public:
      const bool& visited = _visited;
      // 内部方法修改_visited
  };
  

  这种模拟实现存在漏洞：外部调用者可以通过const_cast去掉引用的const属性，直接修改内部的_visited值，完全绕过了你原本的修改权限限制。原生的readonly语法在部分语言中也存在类似的反射修改漏洞，相比之下私有属性+getter的方式可以更好的避免这类越权修改。
• 无法追踪读取行为
  当你需要调试和定位和visited相关的问题时，通过getter方法可以很方便的加断点、加日志，记录所有读取该属性的位置和调用栈；如果是直接暴露的只读属性，你没有办法追踪读取行为，排查问题的难度会高很多。

内容的提问来源于stack exchange，提问作者Jonghyun Park