The practice of starting with Java’s primitive types, in many textbooks on OO programming using Java, obfuscates, rather than illustrates, the OO paradigm. Why should one start a text focusing on teaching the OO paradigm by featuring the part of Java that is not object-oriented? Why, in a programming language that has continued the evolutionary trend toward abstraction by eliminating pointer types, should a student encounter at the outset the machine representations ‘int’, ‘byte’, ‘long’, ‘float’, and ‘double’ the OO paradigm is supposed to be hiding?
Primitive types are a weakness of Java for several reasons: they violate the principle of orthogonality in language design; they owe their existence partly, if not wholly, to optimize performance, violating the design principle with respect to optimization.
“Rule 1: Don’t do it. Rule 2: (for experts only) Don’t do it yet—that is, not until you have a perfectly clear and unoptimized solution” (M. Jackson, Principles of Program Design, 1976). Although Jackson’s maxim relates to program design, it applies as well to the design of a programming language. Surely, you don’t want to let efficiency hide a language’s primary paradigm.
A further weakness in Java may be its dual ontology of objects and values. In the purest form of the OO paradigm, everything is an object.
A good illustration of the OO paradigm is expression evaluation. There is nothing new here. A well-known Smalltalk tutorial uses arithmetic expressions to introduce the OO paradigm (Smalltalk/Vmac: Tutorial and Programming Handbook, 1991). This is as it should be. Smalltalk’s ontology has only objects.
Also, we should teach expression evaluation using proper objects and classes, because we need to show the OO paradigm is applicable to a domain with which every student of computer science is familiar.
The Instances of Base Classes Are Proper Objects
In Java, objects in the base classes (Integer, Real, Character, Boolean) are anonymous. The symbols 1, 2, 3 … are values, not names for integer objects. Similarly, a, b, and c, … are values, rather than identifiers, for the elements of a character set. Likewise, ‘true’ and ‘false’ are values, not identifiers of the two Boolean objects.
Anonymity of objects in the base classes is at variance both with ordinary discourse and mathematical tradition. In ordinary discourse, 1, 2, 3, … are names for the number 1, the number 2, the number 3, and so on. The mathematical tradition beginning with Frege, inventor of first-order logic, treats each integer as an immutable mathematical object (G. Frege, The Foundations of Arithmetic, 1980).
The objects of arithmetic expressions, then, are named objects in mathematical sets. There is an integer object whose identifier is 1, an object whose identifier is 2, and so on. Objects in base classes should have reserved identifiers. Moreover, each integer is a constant. Similarly, the objects of character expressions are named objects in a character set; and ‘true’ and ‘false’ are named Boolean objects.
While Java permits primitive values to be encapsulated in “wrapper” classes, what is encapsulated is a representation, not an object. This raises the following question: Is data representation in Java being confused with object encapsulation? Is the machine domain being confused with the application (real-world) domain? (M. Jackson, Problem Frames, 2000).
Why should one start a text focusing on teaching the OO paradigm by featuring the part of Java that is not object-oriented?
In a “pure” OO ontology, there are only objects. Objects are either composite—they reference properties (which are objects)—or simple (they reference no properties). Java’s dual ontology violates Occam’s razor, or principle of parsimony, that states: “entities must not be multiplied beyond what is necessary” (R.T. Carroll, The Skeptic’s Dictionary; skepdic.com/occam.html).
The simplest model is not only likely to be correct, it is likely to be more teachable.
Expression Evaluation Illustrating the OO Paradigm
Using objects in integer expression evaluation illustrates several features of OO programming, specifically, collaboration, composition, and cascaded method calls.
The accompanying table contains simple expressions illustrating the elementary concepts of the OO paradigm (I have omitted inheritance from the table for the sake of brevity, and to keep the discussion elementary).
For example, assume that a, b, and c are Integer objects in the following expression: a + b * c.
If this is a Smalltalk expression, then a is an object that receives the message + b (in Smalltalk, there is no operator precedence; arithmetic expressions are evaluated left to right). A new object is created with the result of a + b, and this object receives the message * c. The result is a new Integer object.
In textbooks teaching the OO paradigm using Java, wrapper types are introduced after primitive types. The better way to teach the OO paradigm is to teach expression evaluation using simple objects and to leave optimization until later—or to an optimizing compiler.
Teaching expression evaluation using primitive types is harmful in our efforts to teach the OO paradigm. This raises some doubts about Java as an exemplar programming language for teaching the OO paradigm.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment