…is the class invariant.
Class invariants and contracts are not about testing. They are about reliability. The purpose of a class invariant is to minimize the state space of the system, both at design time and at run time. A class invariant is an extension to your type system. You will get the most power from them if you think about them and use them in that way. I love dynamic languages, but the people who bitch the most about type systems probably don’t understand how to use them correctly. The compiler is your friend. Static analysis is your friend. Class invariants make types smarter.
Reliable systems fail at the earliest opportunity. Sounds counterintuitive?
The loom stopped instantly if any one of the warp or weft threads broke. Because a device that could distinguish between normal and abnormal conditions was built into the machine, defective products were not produced.
- Taiichi Ohno
Kanban discussion
Kanban Group
Jason Yip | 10-Nov-07 at 7:00 am | Permalink
That might be an example but I’m not sure that’s the “best” example. Having said that, I’m not sure what would be.
Corey Ladas | 10-Nov-07 at 1:22 pm | Permalink
You’re probably right. I’ll change that.
Kent S | 12-Nov-07 at 12:58 pm | Permalink
I think a precondition is the software equivalent of jidoka. ( http://archive.eiffel.com/doc/...../contract/ )
For example, all warp and weave threads must be tight before advancing.
Corey Ladas | 13-Nov-07 at 1:03 am | Permalink
Yes, at that level of abstraction, contracts are certainly about jidoka. Preconditions are kind of a poka-yoke: make it as difficult as possible to pass bad data or call at the wrong time.