Interfaces for Strongly-Typed Object-Oriented Programming Peter S. Canning, William R. Cook, Walter L. Hill, Walter G. Olthoff Hewlett-Packard Laboratories P.O.Box 10490, Palo Alto, CA 94303-0971 Abstract of untyped object-oriented languages like Smalltalk. In- terpreting interfaces as types in a polymorphic lambda This paper develops a system of explicit interfaces calculus is our main technique for moving towards that for object-oriented programming. The system provides goal, We have implemented a type-checker for a typed the benefits of module interfaces found in languages programming language and are using it to test the feasi- like Ada and Modula-2 while preserving the expressive- bility and value of interfaces for object-oriented pro- ness that gives untyped object-oriented languages like gramming. Smalltalk their flexibility. Interfaces are interpreted as polymorphic types to make the system sufficiently pow- Explicit interfaces are useful for clarifying the erful. We use interfaces to analyze the properties of in- role of inheritance in object-oriented programming lan- heritance, and identify three distinct kinds of inheritance guages. Using recent work on the semantics of inherit- in object-oriented programming, corresponding to ob- ance, we describe three distinct kinds of inheritance in jects, classes, and interfaces, respectively. Object inter- object-oriented programming, corresponding respective- faces clarify the distinction between interface contain- ly, to objects, classes, and interfaces. Interface inherit- ment and inheritance and give insight into limitations ance is important in reinforcing the difference between caused by equating the notions of type and class in many interface compatibility and implementation inheritance. typed object-oriented programming languages. Interfac- es also have practical consequences for design, specifica- It also gives insight into the limitations of typed ob- tion, and maintenance of object-oriented systems. ject-oriented languages that equate the notions of type and class. 1. Introduction In a more practical vein, this work addresses im- portant needs and opportunities in object-oriented soft- An important contribution of languages like Ada, ware development. At Hewlett-Packard, large-scale ob- Mesa, and Modula-2 is the explicit separation of the in- ject-oriented software development has suggested the terface and implementation of program modules. The in- need for the benefits that interfaces provide. Object in- terface provides a boundary between the implementa- terfaces provide a useful framework for specifying ob- tions of an abstraction and its clients. It limits the jects when designing a system. Checking them should amount of implementation detail visible to clients. It yield significant gains in productivity and quality in ob- also specifies the functionality that implementations ject-oriented software development. Interfaces may also must provide. be the basis of new tools for organizing object-oriented systems. In this paper we develop a system of explicit in- terfaces for object-oriented programming. The primary In Section 2, we review the significance of inter- goal for the system of object interfaces presented here is faces in large-scale software development. Section 3 de- to allow interface compatibility to be checked at com- velops the notion of object interface in contrast with pile-time (eliminating the possibility of certain run- object implementation and shows the essential role time errors) while preserving the power and flexibility played by polymorphic types. Section 4 discusses vari- Permission to copy without fee all or part of this material is granted provided ous forms of inheritance in object-oriented program- that the copies are not made or distributed for direct commercial advantage, ming, and the difference between the interface and im- the ACM copyright notice and the title of the publication and its date appear, plementation hierarchies in typed object-oriented pro- and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee gramming. Section 5 briefly compares this work with and/or specific permission. other approaches to typed object-oriented programming. 0 1989 ACM 089791-333-7/89/0010/0457 $1.50 October 1-6, 1989 OOPSLA ‘89 Proceedings 457 2, Interfaces ent, they admit an analogous type-theoretic interpreta- tion. In all these cases, interface checking reduces to “The most important recent development in type-checking, for which there is an existing technolo- programming languages is the introduction of gy. Interfaces consisting only of operation names and an explicit notion of interface to stand be- types are weaker than complete behavioral specifica- tween the implementation of an abstraction and its clients.” tions. Nevertheless, this compromise has proven success- ful in practice, both in terms of expressiveness, user ac- Burstall and Lampson, 1984 ceptance and automated support from compilers and pro- When analyzing and designing software systems, gramming environments. interfaces enforce conceptual discipline and provide mod- ular specifications and documentation. Checking interfac- 30, Objects and Their Interfaces es may detect conceptual as well as superficial errors. Interfaces are also used in code to declare or annotate variable or operation names, making programs easier to understand and maintain. They provide for generic mod- 3.1. Introduction ules and allow categorizing implementations, support- In this section we develop the notion of separat- ing reuse and library administration. In all these forms, ing interface from implementation in object-oriented interfaces include the idea of a contractual agreement be- programming. Our language model for object-oriented tween providers and users of system components, and programming is patterned after Smalltalk- [GR83]. what it means for the terms of the agreement to be sat- Object-oriented systems are characterized by objects isfied. On the other hand, the contract is given in an ab- which group together data and the operations for manip- stract form that deliberately disregards details of how ulating that data. The operations, called method& can be to accomplish its provisions. invoked only by sending messages to the object. Sending Ideally, interfaces should contain a formal de- a message names the operation and supplies necessary ar- scription of the behavior of operations, for example as a guments, but does not determine how the operation is logical theory. Module connections would then be vali- implemented, The target of the message (the receiver) dated by theorem proving. There is much work in pro- determines what action takes place when the message is gram specification and validation that is motivated by received. Since the data (instance variables) in an object this model lEM85, GHW85]. However, this approach can be accessed only by the methods of that object, and requires mechanical theorem proving support which is methods can be invoked only by sending messages, ob- currently an obstacle for including it in practical pro- jects are encapsulated data abstractions. gramming languages. Moreover, the application of speci- Our goal is to provide a language with the flexi- fication and validation techniques to object-oriented pro- bility of Smalltalk, but with the additional structure gramming is not yet well understood. and protection that comes from making interfaces ex- Interfaces have been used in a variety of ways in plicit, and verifying the safety of message sends at com- traditional software development. During design, inter- pile-time. The rest of this section describes object im- faces are typically semi-formal descriptions of how an plementations and then object interfaces. The basic ideas abstraction interacts with the rest of a system. Together in this section have appeared in previous work, as dis- with appropriate naming and documentation conven- cussed in Section 5. In our treatment of recursive and tions, they provide partial specifications. In the imple- polymorphic interfaces, we have attempted greater con- mentation phase, interfaces usually describe the names sistency with object-oriented programming. and the parameter and result types of operations sup- plied by a module as in Ada, Mesa, and Modula-2. In Ada, for example, one distinguishes between package 3.2. Object Implementations specification and package body. The package specification As described above, an object is a collection of in- presents an interface as a list of type, procedure and otb- stance variables and methods. Each method provides a er declarations. Explicit interfaces are important in real- concrete implementation of some abstract operation. A izing data abstraction, data encapsulation and separate compilation. method can implement an operation by manipulating the instance variables, giving them new values or sending In Ada, Mesa, and Modula-2, the module inter- messagesto them, or by sending messages to self. Fig- faces can be interpreted as types [BL84]. While the ob- ure 1 shows an example of a definition of an object ject interfaces discussed below are structurally differ- October l-6, 1989 458 OOPSLA ‘89 Proceedings instance will have, the code for each method, and how object origin implements Point to create instances. Figure 3 shows a class for objects variable rho:Real := 0.0 similar to the object from Figure 1. variable theta:Real := 0.0 class polargoint(x:Real, y:Real) method x0 returns