Programming Languages (CSC-302 98S)
Outline of Class 35: Perspectives on Object-Oriented Programming
Held: Wednesday, April 29, 1998
- The exam is now graded. I've written an
answer key to help show what I
would have liked (and to emphasize some of the things you got wrong).
This was clearly a bimodal distribution, with few scores in the 80s.
Note that I continue to be dismayed at your ability to think about
- Tomorrow at 4:30, three math majors will be discussing internship
experiences. I strongly encourage you to go and learn about what kinds
of cool things Grinnell students are able to do.
- If you signed up for the picnic and are planning to do "FOG Fast", you'll
need to talk to dining services to see if there's an alternative (e.g.,
skipping dinner on Thursday).
- If you haven't done so already, you should read the chapters in Louden
on Object-Oriented Programming (chapter 9) and Semantics (chapter 12).
- Any questions on assignment
- Generate and Test. The first predicate on the right hand
side generates a sample solution. The remaining predicates test the solution.
- General form:
pred(X) :- generate(X),test(X).
alternative(X) :- musician(X),ancestor(velvet_underground,X).
- Variant form:
pred(X) :- generate(Y),test(X,Y).
cool(X) :- coolInstrument(Y),plays(X,Y).
- Loops. You can use Prolog's backtracking strategy to make it
loop by using
fail as the last predicate in a sequence.
- In general, this is only useful if you're doing I/O in the body of
- General form:
loop(X) :- generate(X),write(X),fail.
members(L) :- member(X,L), write(X), nl, fail.
There are a number of topics in Prolog and logic programming that
we haven't covered for issues of time. What are these topics? They
- Other implementation methods.
- Negation: how do we handle it other than "can't prove it, it must
- Unification: how does Prolog match variables and atoms when the
same variable may appear multiple times? [You should have learned
this in CS301].
- Problems with the standard unification algorithm:
concat(, E, [a,b|E]) computes forever (or at least
until the implementation gives up).
"forever" (or at least until the implementation gives up)
- Ugly implementation-oriented issues, such as the cut operator
which permits you to modify the search tree.
- Computer Scientists have developed a number of strategies for looking
at algorithm and data design, including
- procedural / imperative
- While individual definitions of each category may differ, most
definitions have some similarities.
- As you might guess, object-oriented languages concern themselves with
- You might have a sense of what a "real world" object is.
- In computerese, an object is a collection of information
(sometimes called "attributes") and operations that
the object can perform (called "methods").
- 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.")
- When creating new objects, we must specify the class to
which they belong.
- Most object-oriented languages support inheritance, in which
classes can be based upon other classes. For example, we
might say that trees are a subclass of plants.
- A subclass "inherits" the attributes and methods of its
- Many object-oriented languages are event-driven. That is,
you can specify "when this event happens, call this method
of this object."
- 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
- For example, you might know that a
Menu object can
draw menus on the screen, but it's not important to you how it
- Inheritance (also called "subclassing") is one of the important features
of most object-oriented languages.
- When one class subclasses a superclass (inherits from another class)
it incorporates the superclass and acts as the superclass.
- The methods provided by the other class are automatically provided
by the subclass.
- Any fields in the superclass are included in the subclass (althouth
they may not be accessible; see our discussion on protection).
- Any member of the subclass can be used in place of a member of the
- Why do we subclass?
- To add capabilities. "I'd like a list that also provides a
current element." (Adding a field and a number of related
- To change capabilities. "I'd like a picture that increments a
counter whenever it's drawn." (Changing the "draw" method.)
- To restrict capabilities. "I'd like a list that doens't provide XXX".
I'd like a list whose
insert doesn't throw exceptions.
- To take advantage of methods that use the superclass. "Hmmmm ...
Jack and Jane wrote a function that draws a spiral of circles; without
changing their function can I have it draw a sprial of other pictures."
"I can compute the square root of a real number; can I also compute
the square root of complex numbers."
- To design methods that can act on a variety of classes. "If an object
provides a draw method and a resize method, then I can draw a spiral
of that object."
- How do we subclass?
- Usually with some command that says "I'm a subclass of X".
- Are there interesting design decisions in subclassing?
- Can you subclass 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 of X, how
do we choose which method to call?
- 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
- Is there some "root" object class?