Object-oriented Programming and Languages

(This is chapter 10; we will come back to chapter 9)

Initial OO insight: data and operations belong together

We can associate data and operations in one data structure. Such data structures have come to be called objects. Another way to say it: associate state and behavior in one data structure.

Two schools of terminology:

• Behaviors are response to messages (i.e. send message to object)
• Behaviors are procedures that are called using method invocation
• The two are the same (and I dislike the "send a message" terminology because it conflicts with a similar but different use in operating systems, distributed systems, and agent programming.)

Second OO insight: abstraction / interface

Clients/users of an object should not have access to its state except via a defined interface - a set of operations often expressed in application level terms rather than implementation level terms. Example:

• Sets. Application level operations: union, intersection, member
• Sets may be implemented lists, but the interface doesn’t reveal this (maybe it should. Discuss why?)
• Interface: what are the legal operations on the object and what do they do. The signature of an object contains the names and types of all its visible operations and the names and types of all its visible data members. A signature isn't a complete specification of an interface because doesn’t it doesn’t say what the operations mean (semantics).

Note that here we are using the word interface to mean the abstract notion of what what operations an object has and what functionality they have. Some programming languages, for example Java, have language constructs called interfaces that in this lexicon would be called signatures. In almost all languages in widespread use interfaces are specified as a combination of a signature that the compiler understands and a description of meanings in comments (which the compiler and other language tools do not process).

Third OO insight: subtyping

Once we begin to discuss interfaces, we realize:

• If the interface of object A provides all the operations that object B does then A can be used whenever B can. Write A<: B
• It is clear what "provides all the operations of" means for signatures
• Same operation names taking operands of same types
• It is not so clear what it means for semantics of objects: just because object A has a method foo(int) and object B has a method foo(int) it is not necessary that their behavior is related in any way.
• To get around the fact that the language processor doesn’t understand programmer's intentions, OO languages usually require programmers to state their subtyping intentions explicitly. Furthermore, languages often combine subtyping with inheritance -- see below -- but the two are actually separate notions)

Fourth insight: Dynamic dispatch

Suppose: v₁ is value of type I₁ and

 v₂ is a variable of type I₂ and

y is a variable of type I₂

where I₁ <: I₂.

By the definition of subtyping

   if(...) {
      y := (v1: I1)
   } else 
      y := (v2:I2)
   }

is legal because any value of a subtype can be used whenever a value of its supertype can be used.

Suppose further that both types I₁ and I₂ have methods named m and that later in the program we find the expression y.m(...).

Which m should be called: it might be either v1.m or v2.m. OO languages use a mechanism called dynamic dispatch to choose which method to call based on the current binding of the variable. We will talk about the implementation of dynamic dispatch when we talk about C++.

Fifth insight: Inheritance

Proper use of subtyping requires values of a subtype to implement the operations of its supertype with similar meaning. What is an easy way to accomplish this? Let the operations of the subtype be the same as the operators of the supertype. (There are lots of fine points here: such attributes like private, protected, public, etc.)

Note well that inheritance is a property of implementations while subtyping is a property of interfaces:

• Many OO languages tangle the two in a single mechanism called subclassing.
• A class defines an interface and possibly an implementation of (parts of) it.
• A subclass inherits implementations from its superclass, possibly extends (widens) the interface of its superclass, and possibly overrides the superclass implementations with ones of its own.

(C++ subclassing also allows restricting (narrowing) the interface which means a C++ subclass may not be a subtype of its superclass).

Once a class is defined, objects that have that type are called instances of the class.

Warning: on p. 284, for "typed languages" read "statically typed languages" and for "untyped languages" read "dynamically typed languages".

Object-oriented Python

Basic syntax:

class classname [(supername [,supername]+)]:
       suite

In the suite put method function definitions. Each method's first parameter inside a class is always self. For example:

class classname [(supername [,supername]+)]:
   def __init__(self, p1, p2,pn):
      suite
   def m1(self, p1, p2):
      suite
   def m2(self, p1):
      suite

In Python all method names must be unique -- there is no ad-hoc polymorphism based on method name overloading.

To create a new instance of a Python object write

   className(parameters of the __init__ method)

The __init__ method is special: it is called immediately after a new object is constructed and is typically used to initialize the member data of the object.

Here is a simple, non-sensical class illustrating some of these features.

   class myclass(parent):
      imAStaticMember = 37
      def __init__(p1):
         parent.__init__(self)
         self.a1 = 1
         self.a2 = "x"
         self.a3 = p1
      def update(self,p1):
         self.a3 = p1

Note: data members of instances are created in the __init__ method or by subsequent assignment. Class-level data members are created in the class suite itself and act like static members in C++.