Class 33: Object-Oriented Programming

Held Friday, April 23

Summary

• Exam 3 distributed. Due Friday, April 30.

Contents

Handouts

Notes

• Exam 3 is available. Let me know if you have questions.
• How many of you know or have used an object-oriented language?
• Please read chapter 7 of Louden for next week.
• Reminder: outlines of your presentations are due on Monday.

What is Object-Oriented Programming?

• What is object-oriented programming? There are a number of perspectives.
  • One can think of object-oriented programming as a programming paradigm in which parts of a program are objects, rather than procedures, functions, or assertions.
  • One can take the perspective view that object-oriented programming languages were often designed for modeling and simulation.
  • One might view object-oriented programming as a natural extension of type theory.
  • More recently, many have taken the view the object-oriented programming is a technique designed to support greater code reuse.
• As you might guess, object-oriented programming is based on objects. What is an object?
  • Typically, something that includes both data (fields) and functionality (methods).
• Objects communicate by sending messages to each other. In most object-oriented languages, sending a message is similar to calling a function in a procedural language.
• We often group objects into classes.
  • Classes specify common aspects of objects. For example, ``all integers have a value and support addition, subtraction, ...''.
• From the modeling perspective, objects give us a way to model real-world objects.
  • A bank account has a balance, account number, and some other information. It supports deposits and withdrawals.
  • A line at the bank has customers in it and supports the addition of people to the end of the line and the removal of people from the front of the line.
• From the type perspective, objects give us a way to model some compound types, particularly types in which we care about functionality more than values.
  • A stack is something that stores data and that supports the methods push, pop, and peek.
  • A point on the plane has an x and a y coordinate. It supports extraction of those two coordinates (and, possibly, other operations).
• Are objects the only key component of object-oriented languages? No. Most computer scientists expect object-oriented languages to support inheritance and polymorphism.
  • You'll find different definitions for the two, but we'll work on some today.
• Object-oriented languages are also appropriate for information hiding: it may be possible to get information on what an object does, but not necessarily how it does it.

Inheritance

• Inheritance (also referred to as ``subclassing'') is a technique for building a new class (or object) from an existing class.
  • A subclass inherits the methods and fields of its superclass.
  • A subclass may add new methods or fields.
  • A subclass may change (override) methods of the superclass.
• In some sense, inheritance is also a form of subtyping: every element of the subclass is a member of the superclass.
  • This may seem odd, in that the members of the subclass may be ``bigger'' (have more fields).
• For example, we might have a general DrawableObject class and refine that to particular drawable objects, such as Circle or Square.
  • Both Circle and Square will inherit aspects of DrawableObject such as a location and a draw methods.
  • Both Circle and Square will override the draw method to draw a particular kind of object.
  • Circle or Square might
• There are many basic uses for inheritance. Here are a few (we'll see a few more as we consider polymorphism).
  • Inheritance provides some core functionality for new classes. It permits you to begin with much of your code working.
  • Inheritance lets you add capabilities. For example, ``I'd like a list that gives you a current element.''
  • Inheritance lets you change capabilities. For example, ``I'd like a list that keeps track of the total number of things added to it.''
  • Inheritance provides a guarantee of functionality. Since an object inherits all of the ancestors' methods, someone using the object knows that they will all be available.
• Many people think of subclassing as reflecting the ``is a'' relationship. For example, a car is a wheeled vehicle, and a wheeled vehicle is a vehicle.

Polymorphism

• A related concept is that of polymorphism. In a polymorphic language, it is possible to apply the same function to values of different types, and have the behavior be based on the types of the objects.
  • In polymorphism in object-oriented languages, the same function body is used, irrespective of parameters.
  • You may have also seen overloading, in which the function body may depend on the parameters.
• In many/most object-oriented languages, it is possible to use a member of a subclass in place of a member of a superclass.
  • If we know how to use DrawableObjects, then we know how to use Circles and Squares.
  • The methods of the subclass are typically used in place of the methods of the superclass.

Reuse

• Both polymorphism and inheritance help support reuse.
  • They focus on different kinds of reuse (which you might think of as internal and external).
• Through inheritance, you are able to reuse similar code for the methods and fields of a class, only changing that which needs to be changed.
• Through polymorphism, you are able to reuse a function that acts on objects on a broader variety of objects.

The Design of Object-Oriented Languages

• What are some interesting issues in the design and implementation of object-oriented languages? Most have to do with inheritance and polymorphism.
• Can you inherit from multiple classes?
  • Why would you want to?
  • What are the dangers in doing so?
• When working with a reference to an object that we've identified as being in class X, but may actually be in a subclass, Y, of X, that overrides some method, m, how do we choose which version of m to call?
  • Should we use the overridden method by default?
  • Should we use the original version by default?
  • Whichever default we choose, can we still indicate the other? If so, how?
• When we call a polymorphic method whose version depends on the class of the parameter, how far do we go in determining the type of the object.
• Is there some "root" object class?
• Where are the methods of a class defined? Do they need to be defined together, or can they be defined separately?
  • In Java, you define all the new methods for a class in one file.
  • In C++, you can define them in separate files (in fact, you can even define new methods for an existing class).
• ...

Multiple Inheritance

• Of these, one particularly important issue is that of multiple inheritance.
• Multiple inheritance is both a useful and problematic addition to an object-oriented language.
• We've already seen some reasons to do that, such as the ``scalable, drawable, thingamabob''. Here are some others:
  • Here's something that we can both draw and add. (E.g., a Vector)
  • Here's something that we can compute with and print out. (E.g., almost any number.)
  • Here's something like a tree that also permits us to iterate over the elements it contains.
• But ...
  • What if A subclasses both B and C and B and C each provide a foo method that A does not override. Which do we get when we call foo on a member of A?
  • What if A subclasses both B and C and B and C each subclass D? When we create an element of class A do we get one or two ``elements'' of class D?
  • How many of these questions should be under programmer control?
  • Can we guarantee efficient access to fields and methods for the member functions of B and C?
• Because there are two somewhat distinct uses of inheritance and subclassing (reuse of procedures and fields vs. polymorphism), some object-oriented languages provide different mechanisms for the two.
  • Java uses inheritance for the first and ``interfaces'' for the second.
• Note that multiple inheritance includes some aspects of set union for types: something that inherits from both X and Y is both an X and a Y.

History

• Created Tuesday, January 19, 1999 as a blank outline.
• Filled in the details on Friday, April 22, 1999. These details are a synthesis of outline 35 and outline 36 of CS302 98S and outline 10 of CS152 99S, although much of the content was rewritten during synthesis.