Re: Invariant

Responding to Johansson...

I'm reading some paper from the University.

It says
External invariants
- Type invariant
- Abstraction invariant
- Relates to the abstraction itself, regardless of the implementation.
- Visible from outside
- Documented with the external documentation(API)

Too bad the author didn't define the terms. B-) I didn't reply originally because I had no clue about precise definitions for the first two. Since no DbC theory maven has jumped up I am feeling a bit less ignorant and I suspect this is not a common terminology.


One example on en external invariant is if you hava a linkedList and
you check from the client if size() > 0.
This size() > 0 is an external invariant.

I am uncomfortable about calling this example an invariant on the LinkList. It implies that _this particular client_ should always be getting a LinkList where size > 0. That seems to me to be a precondition on the client's usage context, not LinkList.

Conversely, if /all/ clients should operate on a LinkList that is not empty, then that is a precondition on the whatever LinkList behaviors are being accessed. That precondition can be checked by LinkList itself so it isn't external.

Bottom line: I am not sure what the author is getting at here. In fact, I am hazy on what an external invariant is. My best guess is that the author may be addressing a reuse context issue. For example, a general purpose linked list is perfectly valid if it is empty and that might apply in Application A. However, in Application B the expectation is /always/ that the linked list is not empty. That is a context-dependent constraint (i.e., external to the LinkList) but it needs to be supported somehow in the LinkList interface so that it can be validated. In that case, the interface should abstract the support as much as possible to provide the most fundamental information (i.e., size) necessary for validation in the external context.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.