共享对象会破坏封装吗？

问题描述 投票：0回答：1

封装原则说：“你应该隐藏类的属性，只让它们通过方法访问。这保证了类不变量的有效性。”

我完全同意这个原则，但我一直想知道：“在几个类之间共享同一个对象是否会破坏封装？”

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

  • B类有这个对象的引用
  • C 类拥有对此对象的引用

这似乎很荒谬，因为 OOP 的要点是让对象在它们之间进行通信，但问题是一个引用此共享对象的类可以修改而不通过其他类的方法，因此从逻辑上讲它破坏了封装？

例如：B因为没有通过其方法而未经C同意而修改了对象A的状态？对于不通过 B 的 C 也是如此。

我对所有这些原则感到非常困惑，我觉得它们都是相互矛盾的。我是否误解了封装的原理？

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();
  }
}
java oop encapsulation
1个回答
0
投票

是的，像这样共享mutable状态确实是对封装的轻微破坏。需要意识到的一些重要事情：

这并非不可避免

很多类是不可变的。你无法改变他们的任何事情。简单地说，例如字符串。如果 2 个实例都“共享”一个字符串，并且其中一个实例调用 

x.toLowerCase()
，则什么也不会发生。因为 
toLowerCase()
没有改变任何东西。它创建一个全新的字符串并返回它。如果一个类写入 
x = x.toLowerCase()
，则它们正在更新其引用 - 它不会修改另一类的字段所引用的引用（或对象）。

因此共享不可变对象不会遇到这个问题。

架构争论的要点

这是一条没有例外的规则：“每条规则都有例外”。

封装的原则是一个指导。而且，像所有指南一样，真正的专业知识包括知道何时忽略它们。

作为一般原则，封装具有优势。

但是共享状态也是如此。

优点和缺点完全不同。因此，这是一个权衡：您编写的以某些方式破坏封装的代码具有某些缺点。例如，如果不至少考虑到您需要考虑它对涉及“中断”的其他类的影响，就很难更新一个类。但是，通常，两个类在根本上是相关的无论如何——改变一个类而不记住另一个类的存在无论如何都是一个问题。在这一点上，这个特殊的缺点是无关紧要的。

没有简单的指南。即使您觉得自己真的很擅长阅读这样的架构文档，但如果不是经验丰富的程序员，就没有真正的方法可以完全理解如何应用它。

这是一个好消息，也是一个坏消息：要成为一名优秀的程序员，您需要做很多事情并获得 10 年的经验。缺点是：不存在快捷方式。好处是：不存在捷径——所以你可以忽略这些担忧。

如果您提出的某些架构设计最终成为一场灾难，并且如果您付出更多努力来避免封装就可以避免它，[A]这并不意味着替代方案会更好，并且[ B] 那么，你知道初级程序员如何变成专家程序员吗？通过称为“错误”的工具。珍惜他们。并确保您记住，对您的编码决策进行事后分析至关重要。您应该花更多的时间考虑您过去所做的选择对当今软件的可维护性的全面影响，而不是尝试阅读关于“封装”等抽象概念的善意的哲学官方书籍。我并不是说封装之类的东西毫无意义；我只是说封装之类的东西没有意义。一点也不。我的意思是：如果没有个人经验，要有意义地应用这些建议是非常困难。

请注意，我之前关于不可变的建议必须同样遵守所有这些。不要不要继续疯狂地说“我已经看到了光明，一切都将是不可改变的！”是时候扔掉我们所有的软件并重新开始了！” - 这犯了同样的错误。它是工具箱中的一个工具，如果你不断遇到感觉像“封装”的问题，你可能想尝试一些具有更不可变架构的功能。相信我，您会遇到一系列全新的缺点和维护难题。但是，现在您已经了解了，现在您可以权衡前述适当封装的缺点和过度索引的缺点。在下一个项目中，您最终可能能够对哪种权衡最适合您正在从事的项目做出良好的判断。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.