共享对象是否会破坏面向对象的封装性？

封装原则指出："应隐藏类的属性，仅通过方法使其可访问，以此保证类不变式的有效性。"
我完全认同这一原则，但一直存有疑问：共享同一对象给多个类是否会破坏封装性？

示例：我们有一个A类的对象：

• B类持有该对象的引用
• C类持有该对象的引用

这看似矛盾，因为面向对象编程（OOP）的核心就是对象间的交互，但持有共享对象引用的类可绕过其他类的方法修改对象状态，从逻辑上看这是否破坏了封装性？

例如：B类无需经过C类的方法就修改了A类对象的状态，未获得C类的“同意”；C类同理也可绕过B类操作A类对象。
我对这些原则感到困惑，觉得它们彼此矛盾，是否我误解了封装原则？

public class A {
  private int value = 0;

  public void increment(){
    value += 1;
  }

  public void decrement() {
    value -= 1;
  }
}


public class B {
  private final A a;
  
  public B(A a){
    this.a = a;
  }

  public void doSomething(){
    // Do some stuff
    a.increment();
  }
}

public class C {
  private final A a;
  
  public C(A a){
    this.a = a;
  }

  public void doSomethingElse(){
    // Do some stuff
    a.decrement();
  }
}

你并没有误解封装原则，共享对象本身没有破坏封装性，问题核心在于对封装边界的理解：

1. 封装的核心是类自身的状态控制
   封装的本质是让类自己掌控内部状态的修改逻辑。A类把value设为私有，只通过increment()和decrement()暴露合法的修改方式——这已经完全符合封装原则。不管是B还是C，都只能通过A提供的方法修改状态，没有绕过A的控制直接操作私有属性，所以A的封装是完整的。

2. 混淆了“封装”和“类间协作”
   你觉得矛盾的点，是把“多个类共享对象”和“类之间的业务协作约束”混为一谈了：

   • B和C之间不需要互相“同意”修改A，因为A的状态责任在A自己身上，不在B或C。只要A的方法能保证自身的不变式（比如value的合法性），不管谁调用这些方法，都没有破坏封装。
   • 如果B和C的逻辑因为A的状态变化产生冲突，这是业务逻辑层面的协作问题，不是封装的问题。比如需要保证B和C对A的修改有顺序或约束，应该通过更高层的控制类协调，或者在A类里增加更严格的状态校验，和封装原则本身无关。

举个现实例子：你有一个银行账户（A类），把账户信息告诉了家人（B类）和朋友（C类），他们都能通过银行的合法渠道（A的方法）存取钱——这并没有破坏银行账户的封装，因为账户状态始终由银行（A类）管控。至于家人和朋友的操作会不会互相影响，那是你们之间的约定问题，和账户本身的封装无关。

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