什么是java中的类不变量？ [英] What is a class invariant in java?

问题描述

我搜索了该主题，但除了维基百科之外，我没有找到任何其他有用的文档或文章。

I googled the topic, but besides Wikipedia I didn't find any further useful documentation or articles.

任何人都可以用简单的语言向我解释它的含义或者向我推荐一些简单易懂的文档吗？

Can anybody explain to me in simple words what it means or refer me to some nice and easy to understand documentation?

推荐答案

这并不意味着特别指向java。

It doesn't mean anything in particular in reference to java.

类不变量只是一个属性对于类的所有实例，总是，无论其他代码是什么。

A class invariant is simply a property that holds for all instances of a class, always, no matter what other code does.

例如，

class X {
  final Y y = new Y();
}

X具有类不变量，即 y 属性，它永远不会 null ，它的值为 Y 。

X has the class invariant that there is a y property and it is never null and it has a value of type Y.

class Counter {
  private int x;

  public int count() { return x++; }
}

无法保持两个重要的不变量

fails to maintain two important invariants

1. 由于可能出现下溢， count 永远不会返回负值。


2. 那对 count 的调用严格单调增加。

1. That count never returns a negative value because of possible underflow.
2. That calls to count are strictly monotonically increasing.

修改后的类保留了这两个不变量。

The modified class preserves those two invariants.

class Counter {
  private int x;

  public synchronized int count() {
    if (x == Integer.MAX_VALUE) { throw new IllegalStateException(); }
    return x++;
  }
}

但未能保留调用<$的不变量c $ c> count 总是正常成功（没有TCB违规^†）因为 count 可能会抛出异常或者它如果一个死锁的线程拥有计数器的监视器，则可能会阻塞。

but fails to preserve the invariant that calls to count always succeed normally (absent TCB-violations^†) because count might throw an exception or it might block if a deadlocked thread owns the counter's monitor.

每个使用类的语言都可以很容易地维护某些类不变量而不是其他类。 Java也不例外：

Each language with classes make it easy to maintain some class invariants but not others. Java is no exception:

1. Java类始终具有或不具有属性和方法，因此界面不变量易于维护。


2. Java类可以保护他们的私有字段，因此很容易维护依赖私有数据的不变量。


3. Java类可以是final类，因此可以维护依赖于通过制作恶意子类而不存在违反不变量的代码的不变量。


4. Java允许 null 值以多种方式潜入，因此很难维持具有真正价值的不变量。


5. Java有线程，这意味着没有的类同步很难维护依赖于一起发生的线程中的顺序操作的不变量。


6. Java有一些异常，可以很容易地维护不变量，例如返回带有属性p的结果或不返回结果但更难维护不变量，如总是返回结果。

1. Java classes consistently have or do not have properties and methods, so interface invariants are easy to maintain.
2. Java classes can protect their private fields, so invariants that rely on private data are easy to maintain.
3. Java classes can be final, so invariants that rely on there being no code that violates an invariant by crafting a malicious subclass can be maintained.
4. Java allows null values to sneak in in many ways, so it is tough to maintain "has a real value" invariants.
5. Java has threads which means that classes that do not synchronize have trouble maintaining invariants that rely on sequential operations in a thread happening together.
6. Java has exceptions which makes it easy to maintain invariants like "returns a result with property p or returns no result" but harder to maintain invariants like "always returns a result".

---

† - 外部性或 TCB 违规是一个系统设计者乐观地认为不会发生的事件。

---

† - An externality or TCB violation is an event which a systems designer optimistically assumes will not happen.

通常我们只相信基本硬件在讨论构建在它们上面的高级语言的属性时就像宣传的那样工作，并且我们不变量持有的论点没有考虑到以下可能性：

Typically we just trust that the basic hardware works as advertised when talking about properties of high-level languages built on them, and our arguments that invariants hold don't take into account the possibility of:

• 程序员使用调试挂钩来改变局部变量，因为程序以代码不能运行的方式运行。


• 你的同伴不要不要使用带有 setAccessible 的反射来修改私有查找表。


• Loki改变物理会导致处理器错误地比较两个数字。

• A programmer using debug hooks to alter local variables as a program runs in ways that code cannot.
• Your peers don't use reflection with setAccessible to modify private lookup tables.
• Loki altering physics causing your processor to incorrectly compare two numbers.

对于某些系统，我们的TCB可能只包含系统的一部分，所以我们可能会不要假设

For some systems our TCB might include only parts of the system, so we might not assume that

• 一个a dministrator或特权守护程序不会终止我们的JVM进程，

但我们可能会认为

• 我们可以检查点到可靠的事务性文件系统。

更高级别一个系统，它的TCB通常越大，但是你可以从TCB中获得的东西越不可靠，你的不变量越容易保持，从长远来看你的系统就越可靠。

The higher-level a system, the larger its TCB typically is, but the more unreliable things you can get out of your TCB, the more likely your invariants are to hold, and the more reliable your system will be in the long run.

这篇关于什么是java中的类不变量？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！