Xref: utzoo comp.object:1404 comp.lang.eiffel:991 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!ucsd!hub.ucsb.edu!eiffel!bertrand From: bertrand@eiffel.UUCP (Bertrand Meyer) Newsgroups: comp.object,comp.lang.eiffel Subject: Re: Should a constructor do "work"? Message-ID: <359@eiffel.UUCP> Date: 6 Jul 90 17:40:25 GMT References: <55236@microsoft.UUCP> <181@dumbcat.sf.ca.us> Organization: Interactive Software Engineering, Santa Barbara CA Lines: 31 A class is not just a bunch of operations packaged together. It describes a data type, whose instances must satisfy some consistency constraints, called the ``class invariant''; in Eiffel the invariant is part of the class text. The class invariant usually contains two kinds of clause: some clauses characterize the underlying abstract data type and are common to all its implementations; others only apply to an implementation, or a group of implementations, and are called ``representation invariants''. This has been discussed in detail in various publications. The worst situation that can ever happen in the execution of an object-oriented program - the ``mortal sin'' of object-oriented programming - is to produce an object that does not satisfy the invariant of its class. This annihilates any hope of reasoning about the software system, or of understanding what will happen during its execution. (One guaranteed way of committing the mortal sin is called static binding, but that is another story.) The purpose of having creation operations (constructors) in a class is to make sure that every object will satisfy its class's invariant at creation time. This is a formal requirement in Eiffel (Create must ensure not only its postcondition, if any, but also the invariant). Allocating an object without doing the work needed to ensure the invariant would be a trivial example of the ``mortal sin''. -- Bertrand Meyer bertrand@eiffel.com