Behavioral Subtyping Using Invariants and Constraints a Barbara H. Liskov Jeannette M. Wing July 1999 CMU-CS-99-156 a MIT Lab. for Computer Science, 545 Technology Square, Cambridge, MA 02139 Scho ol of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 The work describ ed in this pap er is based on a Novemb er 1994 ACM TOPLAS pap er, \A Behavioral Notion of Subtyping, by the same authors. This pap er's version has b een submitted to the volume Formal Methods For DistributedProcessing: An Object-Oriented Approach, edited byHoward Bowman and John Derrick. Abstract We presentaway of de ning the subtyp e relation that ensures that subtyp e ob jects preserve b ehavioral prop erties of their sup ertyp es. The subtyp e relation is based on the sp eci cations of the sub- and sup ertyp es. Our approach handles mutable typ es and allows subtyp es to have more metho ds than their sup ertyp es. Dealing with mutable typ es and subtyp es that extend their sup ertyp es has surprising consequences on how to sp ecify and reason ab out ob jects. In our approach, we discard the standard data typ e induction rule, we prohibit the use of an analogous \history" rule, and we make up for b oth losses by adding explicit predicates|invariants and constraints{to our typ e sp eci cations. We also discuss the rami cations of our approach of subtyping the design of typ e families. This researchwas supp orted for Liskov in part by the Advanced Research Pro jects Agency of the Department of Defense, monitored by the Oce of Naval Research under contract N00014-91-J-4136 and in part by the National Science Foundation under Grant CCR-8822158; for Wing, by the Avionics Lab, Wright Research and Development Center, Aeronautical Systems Division AFSC, U. S. Air Force, Wright-Patterson AFB, OH 45433-6543 under Contract F33615-90-C-1465, ARPA Order No. 7597. Keywords: subtyp e, ob ject-oriented design, abstraction function, mutable typ es, invariants, constraints, sp eci cations 1 Intro duction What do es it mean for one typ e to b e a subtyp e of another? We argue that this is a semantic question having to do with the b ehavior of the ob jects of the twotyp es: the ob jects of the subtyp e oughttobehave the same as those of the sup ertyp e as far as anyone or any program using sup ertyp e ob jects can tell. For example, in strongly typ ed ob ject-oriented languages such as Simula 67[DMN70], C++[Str86], + Mo dula-3[Nel91], and Trellis/Owl[SCB 86], subtyp es are used to broaden the assignment statement. An assignment x: T := E is legal provided the typ e of expression E is a subtyp e of the declared typ e T of variable x. Once the assignment has o ccurred, x will b e used according to its \apparent" typ e T, with the exp ectation that if the program p erforms correctly when the actual typ e of x's ob ject is T, it will also work correctly if the actual typ e of the ob ject denoted by x is a subtyp e of T. Clearly subtyp es must provide the exp ected metho ds with compatible signatures. This consideration has + + led to the formulation of the contra/covariance rules[BHJ 87, SCB 86, Car88]. However, these rules are not strong enough to ensure that the program containing the ab ove assignment will work correctly for any subtyp e of T, since all they do is ensure that no typ e errors will o ccur. It is well known that typ e checking, while very useful, captures only a small part of what it means for a program to b e correct; the same is true for the contra/covariance rules. For example, stacks and queues might b oth haveaput metho d to add an element and a get metho d to remove one. According to the contravariance rule, either could b e a legal subtyp e of the other. However, a program written in the exp ectation that x is a stack is unlikely to work correctly if x actually denotes a queue, and vice versa. What is needed is a stronger requirement that constrains the b ehavior of subtyp es: prop erties that can b e proved using the sp eci cation of an ob ject's presumed typ e should hold even though the ob ject is actually a memb er of a subtyp e of that typ e: SubtypeRequirement: Let x b e a prop erty provable ab out ob jects x of typ e T. Then y should b e true for ob jects y of typ e S where S is a subtyp e of T. Atyp e's sp eci cation determines what prop erties we can prove ab out ob jects. We are interested only in safety prop erties \nothing bad happ ens". First, prop erties of an ob ject's b ehavior in a particular program must b e preserved: to ensure that a program continues to work as exp ected, calls of metho ds made in the program that assume the ob ject b elongs to a sup ertyp e must have the same b ehavior when the ob ject actually b elongs to a subtyp e. In addition, however, prop erties indep endent of particular programs must b e preserved b ecause these are imp ortant when indep endent programs share ob jects. We fo cus on two kinds of such prop erties: invariants, which are prop erties true of all states, and history properties, which are prop erties true of all sequences of states. We formulate invariants as predicates over single states and history prop erties, over pairs of states. For example, an invariant prop erty of a bag is that its size is always less than its b ound; a history prop erty is that the bag's b ound do es not change. We do not address other kinds of safety prop erties of computations, e.g., the existence of an ob ject in a state, the numb er of ob jects in a state, or the relationship b etween ob jects in a state, since these do not have to do with the meanings of typ es. We also do not address liveness prop erties \something go o d eventually happ ens", e.g., the size of a bag will eventually reach the b ound. This chapter provides a general, yet easy to use, de nition of the subtyp e relation that satis es the Subtyp e Requirement. Our approach handles mutable typ es and allows subtyp es to have more metho ds than their sup ertyp es. Dealing with mutable typ es and subtyp es that extend their sup ertyp es has surprising consequences on how to sp ecify and reason ab out ob jects. In our approach, we discard the standard data typ e induction rule, we prohibit the use of an analogous \history" rule, and we make up for b oth losses by adding explicit predicates to our typ e sp eci cations. Our sp eci cations are formal, which means that they have a precise mathematical meaning that serves as a rm foundation for reasoning. Our sp eci cations can also b e used informally as describ ed in [LG85]. Our de nition applies in a very general distributed environment in which p ossibly concurrent users share mutable ob jects. Our approach is also constructive: One can prove whether a subtyp e relation holds by proving a small numb er of simple lemmas based on the sp eci cations of the twotyp es. 1 The chapter also explores the rami cations of the subtyp e relation and shows howinteresting typ e families can b e de ned. For example, arrays are not a subtyp e of sequences b ecause the user of a sequence exp ects it not to change over time and 32-bit integers are not a subtyp e of 64-bit integers b ecause a user of 64-bit integers would exp ect certain metho d calls to succeed that will fail when applied to 32-bit integers. However, typ e families can b e de ned that group such related typ es together and thus allow generic routines to b e written that work for all family memb ers. Our approach makes it particularly easy to de ne typ e families: it emphasizes the prop erties that all family memb ers must preserve, and it do es not require the intro duction of unnecessary metho ds i.e., metho ds that the sup ertyp e would not naturally have. The chapter is organized as follows. Section 2 discusses in more detail what we require of our subtyp e relation and provides the motivation for our approach. We describ e our mo del of computation in Section 3 and present our sp eci cation metho d in Section 4. We give a formal de nition of subtyping in Section 5; we discuss its rami cations on designing typ e hierarchies in Section 6. We describ e related work in Section 7 and summarize our contributions in Section 8. 2 Motivation To motivate the basic idea b ehind our notion of subtyping, let's lo ok at an example. Consider a b ounded bag typ e that provides a put metho d that inserts elements into a bag and a get metho d that removes an arbitrary element from a bag.