Gregory M. Kapfhammer

What is a Class Invariant?

Clearly and succinctly define the term class invariant.

A class invariant is a property that is true of all objects of a given class at all times. In this, a property is set of tuples of values and objects are restricted to isolated classes and their interactions within those specific classes. Also, a given class does not include subclasses in relation to superclasses; in other words, each class maintains invariants on its own. Finally, at all times holds for all fully constructed objects from the point of constructor completion on while that object is reachable.

Matt DeNapoli

---

The author defines a class invariant as a property that is true of all objects of a given class at all times. These properties can be subdivided into first-order properties (independent poroperties of individual fields) and higher-order properties (ex. binary relations on a field). Also, the author is most interested in isolated-class invariants, which are the invariants of a class considered seperately from its implementation. Invariants are most easily determined in private classes since they cannot be changed by an outside function. And invariants must only be true at the entry and the exit of the function, i.e. the can be broken and reestablished.

Elizabeth Zehner

---

Brenda Gruber

A class invariant is "a property that is true of all objects of a given class at all times" where a properties are sets of tuples of values for the object's fields. In well designed programs "all objects" refers to isolated class invariants, and "of a given class" includes type invariants (invariants inherited from a superclass).

• Select one of the phrases in your above response and elaborate on it in detail. Make sure that you address the fundamental issues that are responsible for formalizing our understanding of your selected phrase. Make sure that each individual selects a different phrase.

---

The issue with the "all objects" part of the definition arises when considering whether to determine invariants based on that object in a particular program, or any program, thus whole-program invariants versus isolated class invariants. If a program is created with OOP, it would be necessary that the classes themsleves be abstracted from the "whole program", therefore it is necessary that invariants be only subjected to isolated classes rather than the whole program. That is not the common case though. It has been found that whole-program invariants occur most commonly.

Matt DeNapoli

---

The question of "Invariant At All Times?" seems to be the conceptually simplest for me. Invariance only holds for fully constructed objects. Invariants only have to be true upon entry and exit of a function: they can be broken and reestablished within the function and still be considered invariant. And narrowing the scope of time strenthens the potential invariants while weeding out potentially weaker invariants. If an exception is thrown during object constuction or within a function, the object is no longer invariant, i.e. invariants only hold when a function completes correctly.

Elizabeth Zehner

---

Brenda

In a well designed program "objects of a given class" would include type invariants, invariants inherited from its superclass. However the author notes that in reality this is seldom possible and it may be more useful to analyze separate class invariants for each class. Class invariants are more specific than type invariants, but are also more difficult to use because of their private, public, or protected status. In otherwords, we know the object's type, but not necessarily the class.

---

Link to this Page

• Software Design last edited on 14 October 2004 at 2:29 pm by aldenv28.allegheny.edu