Editing Class invariant

{{short description|Unchanging property for all objects of a class}}
{{about|the computer programming concept|the mathematical concept|Equivalence class|and|Invariant (mathematics)}}
{{more citations needed|date=August 2010}}

In [[computer programming]], specifically [[object-oriented programming]], a '''class invariant''' (or '''type invariant''') is an [[invariant (computer science)|invariant]] used for constraining [[object (computer science)|objects]] of a [[class (computer science)|class]]. [[Method (computer science)|Methods]] of the class should preserve the invariant. The class invariant constrains the state stored in the object.

Class invariants are established during [[Constructor (object-oriented programming)|construction]] and constantly maintained between calls to public methods. Code within functions may break invariants as long as the invariants are restored before a public function ends. With [[Concurrent computing|concurrency]], maintaining the invariant in methods typically requires a critical section to be established by locking the state using a [[mutex]].

An '''object invariant''', or '''representation invariant''', is a computer programming construct consisting of a set of invariant properties that remain uncompromised regardless of the state of the object. This ensures that the object will always meet predefined conditions, and that methods may, therefore, always [[Reference (computer science)|reference]] the object without the risk of making inaccurate presumptions. Defining class invariants can help programmers and testers to catch more bugs during [[software testing]].

==Class invariants and inheritance==

The useful effect of class invariants in object-oriented software is enhanced in the presence of inheritance. Class invariants are inherited, that is, "the invariants of all the parents of a class apply to the class itself."<ref>Meyer, Bertrand. ''[[Object-Oriented Software Construction]], second edition,'' Prentice Hall, 1997, p. 570.</ref>

Inheritance can allow descendant classes to alter implementation data of parent classes, so it would be possible for a descendant class to change the state of instances in a way that made them invalid from the viewpoint of the parent class. The concern for this type of misbehaving descendant is one reason object-oriented software designers give for favoring [[composition over inheritance]] (i.e., inheritance breaks encapsulation).<ref>E. Gamma, R. Helm, R. Johnson, and J. Vlissides. ''[[Design Patterns: Elements of Reusable Object-Oriented Software]].'' Addison-Wesley, Reading, Massachusetts, 1995., p. 20.</ref>

However, because class invariants are inherited, the class invariant for any particular class consists of any invariant assertions coded immediately on that class [[Logical conjunction|in conjunction with]] all the invariant clauses inherited from the class's parents. This means that even though descendant classes may have access to the implementation data of their parents, the class invariant can prevent them from manipulating those data in any way that produces an invalid instance at runtime.

==Programming language support==

===Assertions===

Common programming languages like Python,<ref>[https://docs.python.org/3/reference/simple_stmts.html#grammar-token-assert-stmt Official Python Docs, ''assert statement'']</ref> PHP,<ref>{{Cite web|title=PHP assert function|url=https://www.php.net/manual/en/function.assert.php|url-status=live|archive-url=https://web.archive.org/web/20010321003333/http://www.php.net:80/manual/en/function.assert.php |archive-date=2001-03-21 }}</ref> JavaScript,{{citation needed|date=February 2021}} C++ and Java support [[Assertion (computing)|assertions]] by default, which can be used to define class invariants. A common pattern to implement invariants in classes is for the constructor of the class to throw an exception if the invariant is not satisfied. Since methods preserve the invariants, they can assume the validity of the invariant and need not explicitly check for it.

===Native support===

The class invariant is an essential component of [[design by contract]]. So, programming languages that provide full [[Design by contract#Languages with native support|native support for design by contract]], such as [[Eiffel (programming language)|Eiffel]], [[Ada (programming language)|Ada]], and [[D (programming language)|D]], will also provide full support for class invariants.

===Non-native support===

For [[C++]], the [[Loki (C++)|Loki Library]] provides a framework for checking class invariants, static data invariants, and exception safety.

For Java, there is a more powerful tool called [[Java Modeling Language]] that provides a more robust way of defining class invariants.

==Examples==

===Native support===

====Ada====
The [[Ada (programming language)|Ada]] programming language has native support for type invariants (as well as pre- and postconditions, subtype predicates, etc.).  A type invariant may be given on a private type (for example to define a relationship between its abstract properties), or on its full definition (typically to help in verifying the correctness of the implementation of the type).<ref>{{Cite web|title=Ada Reference Manual 7.3.2 Type Invariants|url=http://www.ada-auth.org/standards/22aarm/html/AA-7-3-2.html|access-date=2022-11-27|website=ada-auth.org}}</ref>  Here is an example of a type invariant given on the full definition of a private type used to represent a logical stack.  The implementation uses an array, and the type invariant specifies certain properties of the implementation that enable proofs of safety.  In this case, the invariant ensures that, for a stack of logical depth N, the first N elements of the array are valid values.  The Default_Initial_Condition of the Stack type, by specifying an empty stack, ensures the initial truth of the invariant, and Push preserves the invariant.  The truth of the invariant then enables Pop to rely on the fact that the top of the stack is a valid value, which is needed to prove Pop's postcondition.  A more complex type invariant would enable the proof of full functional correctness, such as that Pop returns the value passed into a corresponding Push, but in this case we are merely trying to prove that Pop does not return an Invalid_Value.

<syntaxhighlight lang="Ada">
generic
    type Item is private;
    Invalid_Value : in Item;
package Stacks is
    type Stack(Max_Depth : Positive) is private
        with Default_Initial_Condition => Is_Empty (Stack);

    function Is_Empty(S : in Stack) return Boolean;
    function Is_Full(S : in Stack) return Boolean;

    procedure Push(S : in out Stack; I : in Item)
        with Pre  => not Is_Full(S) and then I /= Invalid_Value,
             Post => not Is_Empty(S);
    procedure Pop(S : in out Stack; I : out Item)
        with Pre  => not Is_Empty(S),
             Post => not Is_Full(S) and then I /= Invalid_Value;
private
    type Item_Array is array (Positive range <>) of Item;

    type Stack(Max_Depth : Positive) is record
        Length : Natural := 0;
        Data : Item_Array (1 .. Max_Depth) := (others => Invalid_Value);
    end record
        with Type_Invariant => Length <= Max_Depth and then
          (for all J in 1 .. Length => Data (J) /= Invalid_Value);

    function Is_Empty(S : in Stack) return Boolean
        is (S.Length = 0);
    function Is_Full(S : in Stack) return Boolean
        is (S.Length = S.Max_Depth);
end Stacks;
</syntaxhighlight>
====D====
[[D (programming language)|D]] programming language has native support of class invariants, as well as other [[contract programming]] techniques.
Here is an example from the official documentation.<ref>{{Cite web|title=Contract Programming - D Programming Language|url=https://dlang.org/spec/contracts.html|access-date=2020-10-29|website=dlang.org}}</ref>

<syntaxhighlight lang="D">class Date {
  int day;
  int hour;

  invariant() {
    assert(day >= 1 && day <= 31);
    assert(hour >= 0 && hour <= 23);
  }
}
</syntaxhighlight>

====Eiffel====

In [[Eiffel (programming language)|Eiffel]], the class invariant appears at the end of the class following the keyword <code lang="eiffel">invariant</code>.

<syntaxhighlight lang="eiffel">
class
	DATE

create
	make

feature {NONE} -- Initialization

	make (a_day: INTEGER; a_hour: INTEGER)
			-- Initialize `Current' with `a_day' and `a_hour'.
		require
			valid_day: a_day >= 1 and a_day <= 31
			valid_hour: a_hour >= 0 and a_hour <= 23
		do
			day := a_day
			hour := a_hour
		ensure
			day_set: day = a_day
			hour_set: hour = a_hour
		end

feature -- Access

	day: INTEGER
		-- Day of month for `Current'

	hour: INTEGER
		-- Hour of day for `Current'

feature -- Element change

	set_day (a_day: INTEGER)
			-- Set `day' to `a_day'
		require
			valid_argument: a_day >= 1 and a_day <= 31
		do
			day := a_day
		ensure
			day_set: day = a_day
		end

	set_hour (a_hour: INTEGER)
			-- Set `hour' to `a_hour'
		require
			valid_argument: a_hour >= 0 and a_hour <= 23
		do
			hour := a_hour
		ensure
			hour_set: hour = a_hour
		end

invariant
	valid_day: day >= 1 and day <= 31
	valid_hour: hour >= 0 and hour <= 23
end
</syntaxhighlight>

===Non-native support===

====C++====
The [[Loki (C++)]] library provides a framework written by [[Richard Sposato]] for checking class invariants, static data invariants, and [[exception safety]] level.

This is an example of how a class can use Loki::Checker to verify that invariants remain true after an object changes. The example uses a geopoint object to store a location on Earth as a coordinate of latitude and longitude.

The geopoint invariants are:
* latitude may not be more than 90° north.
* latitude may not be less than -90° south.
* longitude may not be more than 180° east.
* longitude may not be less than -180° west.

<syntaxhighlight lang="C++">
#include <loki/Checker.h>  // Needed to check class invariants.

#include <Degrees.hpp>

class GeoPoint {
 public:
  GeoPoint(Degrees latitude, Degrees longitude);

  /// Move function will move location of GeoPoint.
  void Move(Degrees latitude_change, Degrees longitude_change) {
    // The checker object calls IsValid at function entry and exit to prove this
    // GeoPoint object is valid. The checker also guarantees GeoPoint::Move
    // function will never throw.
    CheckFor::CheckForNoThrow checker(this, &IsValid);

    latitude_ += latitude_change;
    if (latitude_ >= 90.0) latitude_ = 90.0;
    if (latitude_ <= -90.0) latitude_ = -90.0;

    longitude_ += longitude_change;
    while (longitude_ >= 180.0) longitude_ -= 360.0;
    while (longitude_ <= -180.0) longitude_ += 360.0;
  }

 private:
  /** @note CheckFor performs validity checking in many functions to determine
   if the code violated any invariants, if any content changed, or if the
   function threw an exception.
   */
  using CheckFor = ::Loki::CheckFor<const GeoPoint>;

  /// This function checks all object invariants.
  bool IsValid() const {
    assert(this != nullptr);
    assert(latitude_ >= -90.0);
    assert(latitude_ <= 90.0);
    assert(longitude_ >= -180.0);
    assert(longitude_ <= 180.0);
    return true;
  }

  Degrees latitude_;   ///< Degrees from equator. Positive is north, negative is
                       ///< south.
  Degrees longitude_;  ///< Degrees from Prime Meridian. Positive is east,
                       ///< negative is west.
}
</syntaxhighlight>

====Java====
This is an example of a class invariant in the [[Java programming language]] with [[Java Modeling Language]].
The invariant must hold to be true after the constructor is finished and at the entry and exit of all public member
functions. Public member functions should define [[precondition]] and [[postcondition]] to help ensure the class invariant.

<syntaxhighlight lang="Java">public class Date {
    int /*@spec_public@*/ day;
    int /*@spec_public@*/ hour;

    /*@invariant day >= 1 && day <= 31; @*/ //class invariant
    /*@invariant hour >= 0 && hour <= 23; @*/ //class invariant

    /*@
    @requires d >= 1 && d <= 31;
    @requires h >= 0 && h <= 23;
    @*/
    public Date(int d, int h) { // constructor
        day = d;
        hour = h;
    }

    /*@
    @requires d >= 1 && d <= 31;
    @ensures day == d;
    @*/
    public void setDay(int d) {
        day = d;
    }

    /*@
    @requires h >= 0 && h <= 23;
    @ensures hour == h;
    @*/
    public void setHour(int h) {
        hour = h;
    }
}</syntaxhighlight>

==References==
{{Reflist|2}}

<!--Categories-->
[[Category:Class (computer programming)]]