Class 33: Object-Oriented Programming
Held Friday, April 23
- Exam 3 distributed. Due Friday, April 30.
- 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? There are a number of
- 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
- 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
- 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
- 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 (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
and refine that to particular drawable objects, such as
Square will inherit
DrawableObject such as a location and
Square will override
the draw method to draw a particular kind of object.
- 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.
- 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
- The methods of the subclass are typically used in place of the methods
of the superclass.
- 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
- Through polymorphism, you are able to reuse a function that acts
on objects on a broader variety of objects.
- 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).
- Of these, one particularly important issue is that of multiple
- 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.
- 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
outline 10 of
although much of the content was rewritten during synthesis.