Talk:Class invariant

I agree they should be merged. Invariants are defined in classes but they are tested in instances. The discussion should take place in one place.

Bad merge?

An object invariant, or representation invariant, is a 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 the object without the risk of making inaccurate presumptions.

This paragraph comes from the article Object invariant before merging it to this article. Object invariant, as defined in this paragraph, doesn't seem to have a different meaning from class invariant. If this is the case, I suggest removing this paragraph completely - or is there something that makes is reasonable to distinguish between class invariant and object invariant? --Abdull (talk) 15:55, 6 July 2010 (UTC)[reply]

When class invariants can be broken

"Class invariants are established during construction and constantly maintained between calls to public methods."

Technically they are maintained between *executions* to methods as opposed to *calls* to methods. This is a subtle but important difference. For example, in Aspect-Oriented Software Development, advice can intercept a call to a method. The invariant may not be broken at this time; it can be broken once the original method starts execution.

"Temporary breaking of class invariance between private method calls is possible, although not encouraged."

Why is this not encouraged?

Khatchad (talk) 19:59, 9 February 2011 (UTC)[reply]

"Class invariants are established during construction and constantly maintained between calls to public methods."

Doesn't this assume there are no other methods on the stack? For example, when setName() is called from reset() in the example below, the class invariant won't be maintained at the start of setName().

class A {
   private String name = "Default Name";
   // Class Invariant: name != null
   // When called from reset(), the invariants of this
   //   class will not hold.
   public void setName(String newName) {
      name = newName;
   }
   public void reset() {
      name = null;
      setName("Default Name");
   }
}

D language

Given the native and almost complete implementation of design by contract in D programming language, I find it hard to believe this page doesn't give a bit more evidence to D, its syntax and ideas. — Preceding unsigned comment added by 79.21.6.82 (talk) 18:33, 15 August 2011 (UTC)[reply]

Prevent?

Currently the article claims "that even though descendant classes may have access to the implementation data of the their parents, the class invariant can prevent them from manipulating those data in any way that produces an invalid instance at runtime." Class invariants prevent corruption about as well as laws prevent crime, i.e., not at all -- unless they are respected. It would be more accurate to say that if the descendant classes all respect the class invariant, then descendant classes don't break invariants; however this is really just like saying that, if everyone obeyed the law, there would be no crime; it's essentially meaningless.

I think the article needs to be clearer about the various levels of enforcement: none, dynamic checks, static checks. Only the last actually prevents corruption.

Also it might be good were the article to explain the relationship between class invariants and and abstraction relations. Theodore.norvell (talk) 18:21, 3 October 2012 (UTC)[reply]

Day/hour constructor inequalities are backwards

Currently, most code blocks include "1 >= a_day". This implies "a_day <= 1" and rejects all days in [2, inf).

This is why I like interval notation, it's hard to get the directions wrong. I think intervals are better than inequalities for defining one variable in terms of other variables/constants, like "this variable is of type Interval<>". It encodes a range of permissible numbers as a "data type".

Maybe inequalities are useful for representing constraints among/between complex clusters of variables and expressions. Which is not the case here.

Should all the code be changed to interval notation? "1 <= a_day"? "a_day >= 1"?

Aksil1337 (talk) 01:46, 16 January 2020 (UTC)[reply]

"1 >= day && day <= 31" is simply wrong and misleading, so it has to be corrected. It doesn't matter that much which notation will be used, as long as it is a valid syntax.

"day >= 1 && day <= 31" keeps variable in the same position for both sub-conditions and "1 <= day && day <= 31" resembles the interval notation. Both seems viable. Although, I would go with the first one.