Held: Monday, 30 August 2004
Summary:
Today we continue our exploration of core course issues by visiting
the object-oriented paradigm and the notions of ADT and data structure.
Assignments
- Nightly assignment: Find at least one definition of object-oriented programming and be prepared to compare it to the one I gave in class.
Notes:
- Still working on the details of the syllabus. Sorry.
- Sorry for the name screwups on Friday. Unfortunately, it will happen again.
Overview:
- Programming Paradigms
- Object-Oriented Programming
- ADTs and Data Structures
- Computer Scientists have developed a number of strategies for looking
at algorithm and data design, including
- procedural / imperative
- object-oriented
- functional
- logical
- declarative
- While individual definitions of each category may differ, most
definitions have some similarities.
- In CS151, you studied functional and imperative design.
- You may have also seen some basic object-oriented design.
- In CS152, you will study object-oriented and imperative design.
- 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).
- For example, we might say that the textbook I used last year
- 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 a method)
- 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 text that you can extract
- 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.
- 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.
- To give the expected time behavior of Scheme lists and vectors, the designers
of Scheme needed to choose particular implementations of lists and vectors.
- Hence, Scheme lists and vectors also have an underlying data structure.
- Remember, the line between ADT and DS was once blurred.
- How are Scheme lists implemented? With cons cells (pairs).
- How are Scheme vectors implemented? With contiguous areas of memory.
;
Check with Bobby