信息隐藏。什么时候是安全性，什么时候是软件权重？答案

【问题标题】：Information hiding. When it is security and when is software weighting?信息隐藏。什么时候是安全性，什么时候是软件权重？
【发布时间】：2013-09-07 10:34:51
【问题描述】：

我正在实现一个 Java 应用程序，我想知道良好的安全性（信息隐藏）和软件可读性之间的平衡点。例如，我定义了一个公共构造函数的许多方法，它内部只有一个对象实例的方法

public class myFrame extends JFrame
{
    /**
     *Constructor
     */
    public myFrame()
    {
        initialize();
    }

    private void initialize () 
    {
       //something that instance a myFrame object
    }

这样，调用 myFrame 构造函数的外部类无法知道 HOW myFrame 实例它的对象，而只接收想要的对象。这个想法可以应用于任何 myFrame 方法，但我发现它不会很好地提高软件的可读性，有让它变得乏味的风险。

那么，在您看来，哪个是好方法？将信息隐藏应用于任何方法或仅用于重要的方法？你会怎么做？

谢谢你，知道你的开发经验会启发我的想法！

【问题讨论】：

信息隐藏不是出于安全考虑。永远不会。除此之外，我没有看到任何隐藏在您的 sn-p 中的信息。
(i) 你不能在一个名为 myFrame 的类中拥有一个名为 TabellaOrario 的构造函数 (ii) 想要查看对象是如何构造的人可以轻松找到你的 initialize 方法以及如何实施。
感谢您的 cmets。您将如何使您的软件更安全？
@Bernheart 以何种方式更安全？您到底想对用户/潜在攻击者隐藏什么？
是的。我认为您在实施时使用信息隐藏。以哪种方式？

标签： java information-hiding

【解决方案1】：

“信息隐藏”一词并不常用。就个人而言，我从未听说过它，我是计算机科学专业的。这就是为什么我们大多数人都如此困惑，而您可能误解了它的原因。

当使用类似于“信息隐藏”的术语时，它实际上是在安全上下文中使用的。隐藏在安全中的信息通常意味着某种形式的security by obscurity - 这意味着它例如尝试通过某种加密和/或混淆来隐藏应用程序内的管理员登录凭据。然而，这样做总是一件坏事，因为它从不起作用。

原来the real meaning of "information hiding"实际上是封装（或非常接近）。现在，这是我们都理解的术语。还有更多与相同问题组合相关的术语，即抽象和实现隐藏。有许多不同的定义，所有的词都有些重叠，甚至有人认为它们是一样的。

不过，有一点是肯定的。信息隐藏、封装、抽象或实现隐藏与应用程序安全没有任何关系以任何方式。它们都与应用程序设计相关，可帮助您实现设计良好、稳定、可扩展且无错误的应用程序。

您的示例并没有以任何方式增加应用程序的安全性（很容易将字节码反编译为源代码），也没有使用封装。

这是封装：

public class MyClass {
    private String someText;

    public String getSomeText() {
        return someText;
    }

    public void setSomeText(String someText) {
        this.someText = someText;
    }
}

私有字段someText被封装了，因为不能直接访问。它必须通过 getter/setter 访问。对字段的直接访问被抽象掉了。现在，虽然这似乎是一项不必要的工作，但它在很多方面都有帮助：

如果将来您决定字符串只应为非空值，则可以将设置器更改为只接受非空值而不破坏任何人的代码
如果您决定分发字符串trimmed，您可以简单地更改getter
如果我们不是在谈论不可变的字符串，而是在谈论可变的List，例如，您可以分发您的列表的防御性副本，这样任何人都无法更改您的列表
如果您不希望任何人更改您的字符串，您可以简单地删除设置器

等等。等等。这种策略使您能够授予/限制对您的字段的访问。它使您能够在将来更改您的班级而不会破坏班级用户的代码。这是向字段声明访问器/修改器的默认方式。

封装、抽象、信息隐藏等更多。字段抽象之后最重要的主题肯定是接口。随意阅读这些主题。

【讨论】：

【解决方案2】：

试图隐藏或构思信息不会给您带来安全感。它只能阻止最弱的攻击者，并且会提供虚假的安全感，这是你能得到的最糟糕的情况。

您的类初始化示例是错误的。首先构造函数不是继承的，因此将您的代码移动到某个私有方法不会产生任何影响。其次，如果想在你的类的构造函数中使用 initialize() 方法，而别处，使用初始化器（也就是初始化块）——它们就是为此而生的。

【讨论】：