Held: Tuesday, January 25, 2005
Summary:
Today we continue our exploration of core course issues by visiting
the object-oriented paradigm and the notions of ADT and data structure.
We also attempt to define our first class of objects.
Related Pages:
Due
Assignments
Notes:
- I did not mention my office hours: M-Th, 1:15-2:05. I also accept walk-ins more-or-less whenever I'm in my office.
- I tend to be sarcastic. Please let me know when it gets to be too much.
- I'll be gone a few times this semester doing "faculty" stuff (reviewing grants for the National Science Foundation, attending a conference, reviewing another department's CS program). Ms. Cassandra Schmitz will generally run labs when I'm not here.
Overview:
- Object-Oriented Programming
- ADTs and Data Structures
- Exercise: Rational Numbers
- Object-oriented languages have two very different motivators:
- The early object-oriented languages were designed to provide a better way to build simulations. In these languages, each program object simulated a real-world object.
- Most modern object-oriented languages use the tools of the early languages to provide an environment that better supports large-scale program design. In particular, good object-oriented languages support
- Information hiding: Limiting the portions of one part of a program that are immediately accessible by other parts of a program.
- Code reuse: Allowing programmers to reuse parts of old programs in new ways.
- As you might guess, object-oriented languages concern themselves with objects.
- You might have a sense of what a
real world
object is.
- In computerese, an object is a collection of information (sometimes called attributes or fields) and operations that the object can perform (called methods).
- We obtain information hiding by limiting the access one has to the fields of the object.
- We often classify methods as observers, which get information but don't change the underlying object, and mutators, which change the underlying object.
- For example, we might say that the textbook I used in the past
- has title
Java Structures
(attribute)
- is published in hardback (attribute)
- was written by Dwayne Bailey (attribute)
- contains text that you can extract (the text is an attribute, the extracting
of the text might be considered an observer method)
- permits you to rip pages out
- We often categorize objects into classes. A class specifies
common aspects of a set of objects. These aspects are often
generic attributes and specifications of methods (E.g., ``all objects in
this class have a color, a size, and can draw themselves''.)
- Almost every book has a title
- Almost every book has one or more authors
- Almost every book has pages
- Almost every book has text on various pages
- Most object-oriented languages support inheritance, in which
classes can be based upon other classes. For example, we might say that
library books are a subclass of books and inherit all the
attributes of books. Library books also extend books.
- Since books have titles, library books also have titles
- Since books have authors, library books also have authors
- Library books also have
loan records
: information on who has
the book.
- A subclass inherits the attributes and methods of its
parent class.
- The parent class is often called a superclass.
- Most object-oriented languages support polymorphism, in which
a member of a subclass can be used in place of a member of a superclass.
- If we know how to read a book, we know how to read a library book.
- Many object-oriented languages are event-driven. That is,
you can specify
when this event happens, call this method
of this object
.
- As mentioned above, a key aspect of object-orientation (and good
program design in any language) is information hiding.
In general, objects should know what other objects do, but
not how they do it.
- For example, you might know that a
Menu object can
draw menus on the screen, but it's not important to you how it
does it.
- This property is also called encapsulation.
- Polymorphism, inheritance, and encapsulation are three key aspects
of object-oriented programming.
- We describe operations (methods, procecures) very differently in object-oriented languages. In general, instead of saying "Apply this procedure to these values", we say "Tell this object to do this operation/method using these additional values".
- For example, instead of saying "print the value 2 to the screen", we might say "screen, please print the value 2" or "2, please print yourself to the screen".
- Similarly, instead of saying "add 2 and 3", we might say "2, please add 3 to yourself and tell me the result".
- It takes a while to get used to this variant way of thinking about operations.
- This semester, we'll talk about data structures and
abstract data types. Some computer scientists treat
them as equivalent terms. I consider them different, although, on
occasion, I use them interchangably.
- An abstract data type (ADT) is a collection of values and
operations on those values. ADTs specify the what of data.
- A data structure is a structure designed to organize data.
Data structurs specify the how of ADTs.
- When we distinguish the two, we sometimes say that data structures
implement abstract data types.
- Those of you coming from the Scheme-based 151 may already be familiar
with two basic ADTs: the list and the vector.
- Both lists and vectors gather data into a sequence.
- More importantly, they provide facilities for manipulating the
sequence.
- You can extract an element from the sequence.
- You can change an element in the sequence.
- (Sometimes) you can insert or remove an element from the
sequence.
- Vectors and lists differ in the operations they provide and the
costs associated with each operation.
- Note that their are typically four issues we will consider when
we work with ADTs:
- Their overall concept: what grounds the design of this ADT or structure (sometimes this speaks to expected efficiency);
- Their relationships to other ADTs: where do they fit in the ADT hierarchy?
- Their functionality: what
methods
the structures provide (the ADT);
- Their applications: how we might use them.
- Similarly, there are three issues we will consider when we work with data structures:
- Their strategy: the central idea in the implementation;
- Their implementation: how they do what they do;
- Their efficiency: how fast they are (or with how much memory they consume); and
- Note that we want a clear barrier between specification and implementation,
so that a client of one of your data structures need only know
what you do and not how you do it. We often call this separation
encapsulation or information hiding.
- This term, we will be looking at each of these aspects of a number of
the key ADTs in CS.
- When designing a new class, you should consider what methods are appropriate for the class.
- As I noted above, we tend to classify our methods in three ways:
- constructors allow us to build new objects;
- observers extract information about an object
- mutators change an object
- These classifications are not perfect, since some operations can fit in more than one classification.
- We'll begin by attempting to list and classify the methods for a rational number (fraction) class.
;
Check with Bobby