Type Inheritance and Relational Theory

Appendix A

Encapsulation Isa Red Herring

This appendix is based on a column that first appeared in Database Programming & Design 12, No. 9 (September 1998). It doesn’t have much to do with the principal topic of this book (i.e., type inheritance) as such—at least, not directly—but it does have certain implications for that topic, which is why I wanted to include it here.

I mentioned the notion of encapsulation several times in the body of this book (mostly in Chapters 21 and 22, but also elsewhere in passing). Encapsulation is widely perceived as a key feature, or benefit, of object technology. But it seems to me that the focus on encapsulation has always been a little bit off base; rather, what’s important, as I tried to explain in Chapter 2, is just to make a clear distinction between types and representations. Indeed, as the title of this appendix indicates, I feel that encapsulation per se is a little bit of a red herring, and in what follows I’d like to try to explain why I feel this way.

WHAT DOES ENCAPSULATION MEAN?

By now you should have a pretty good idea of what encapsulation means, but for the record let me take a moment to spell it out anyway. Basically, a data type is said to be encapsulated if values, and hence variables also, of the type in question have no user visible components (and then those values and variables are said to be encapsulated as well). For example, in their book on Smalltalk (Smalltalk-80: The Language and its Implementation, by Adele Goldberg ...