The document discusses class invariants in object-oriented programming. A class invariant is a global property that must be true for all instances of a class at stable times, such as after object construction or method calls. Constructors and methods must preserve the class invariant. Inherited classes combine the invariants of parent classes with their own invariants. Method redeclarations in subclasses can only weaken preconditions and strengthen postconditions compared to the original methods.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0 ratings0% found this document useful (0 votes)
51 views
Formal Methods - Lecture 16
The document discusses class invariants in object-oriented programming. A class invariant is a global property that must be true for all instances of a class at stable times, such as after object construction or method calls. Constructors and methods must preserve the class invariant. Inherited classes combine the invariants of parent classes with their own invariants. Method redeclarations in subclasses can only weaken preconditions and strengthen postconditions compared to the original methods.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 9
Class Invariants
Pre-conditions and post-conditions describe the properties
of individual methods.
A class invariant is a global property of the instances of a
class, which must be preserved by all methods.
A class invariant is an assertion in the class definition.
E.g. a stack class might have the following class invariant:
count >= 0 and
count <= capacity and stack_is_empty = (count = 0) Class Invariants
An invariant for a class C must be satisfied by every instance
of C at all “stable” times.
“Stable” times are those in which the instance is in an
observable state Example A (mutable) class representing a range of real numbers:
public class RealRange {
private RealNumber min, max; public RealRange(RealNumber min, RealNumber max) { this.min = min; this.max = max; } public void setRange(RealNumber newMin, RealNumber newMax) { this.min = newMin; this.max = newMax; } } invariant: min <= max. The Invariant Rule
An assertion I is a correct invariant for a class C if and only if:
Every constructor of C, when applied to arguments satisfying
its precondition in a state where the attributes have their default values, yields a state satisfying I.
Every method of the class, when applied to arguments and a
state satisfying both I and the method’s precondition, yields a state satisfying I. DbC and Inheritance What happens to assertions when classes are inherited?
How can assertions be “preserved” in the face of
redeclaration (overriding) and dynamic binding?
Actually assertions help maintain the semantics of
classes and methods when they are inherited. Invariants The invariants of all the parents of a class apply to the class itself. The parents’ invariants are added (logically “and”ed) to the class’s own invariants. Class Parent Class Parent Attrs … Attrs … Methods … Methods … Inv: P Inv: P
Class Child Class Child
Attrs … Attrs … Methods … Methods … Inv: C Inv: P C
The parents’ invariants need not be repeated in the class.
Pre and Postconditions A method redeclaration may only do the following:
Pre-condition Post-condition replace the original precondition replace the original postcondition by one equal or weaker by one equal or stronger
The new version must accept The new version must
all calls that were acceptable to guarantee at least as much as the original. the original. It may, but does not have to, It may, but does not have to, accept more cases. guarantee more.
e.g. replace pre: x<10 by e.g. replace post: x<=10 by
pre: x<=10 post: x=10 Summary Software reliability requires precise specifications which are honoured by both the supplier and the client.
DbC uses assertions (pre and postconditions, invariants) as a
contract between supplier and client.
DbC works equally well under inheritance.
Languages with third-party support: • C and C++: DBC for C preprocessor, GNU Nana • C#: eXtensible C# (XC#). • Java: iContract2, Contract4J, jContractor, Jcontract, C4J, CodePro Analytix, STclass, Jass preprocessor, OVal with AspectJ, Java Modeling Language (JML), SpringContracts for the Spring framework, or Modern Jass, Custos using AspectJ. • JavaScript: Cerny.js or ecmaDebug. • Common Lisp: the macro facility or the CLOS metaobject protocol. • Scheme: the PLT Scheme extension • Perl: the CPAN modules Class::Contract , Carp::Datum • Python, PyDBC , Contracts for Python. • Ruby: Ruby DBC , ruby-contract.