Outline of Class 35: Perspectives on Object-Oriented Programming

Held: Wednesday, April 29, 1998

Administrivia

• 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 testing functions.
• 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 six?

Prolog, Concluded

Programming Techniques

• 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).
    

• Example:

  alternative(X) :- musician(X),ancestor(velvet_underground,X).
  

• Variant form:

  pred(X) :- generate(Y),test(X,Y).
  

• Example:

  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 the loop.
  • General form:

    loop(X) :- generate(X),write(X),fail.
    

• Example:

  members(L) :- member(X,L), write(X), nl, fail.
  

What Haven't We Covered?

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 include:

• Other implementation methods.
• Negation: how do we handle it other than "can't prove it, it must be false".
• 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).
  • Given foo(X,bar(X)), foo(A,A) computes "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.

Object-Oriented Languages

• 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.
• 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") 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 parent class.
• 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 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.

Inheritance

• 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 superclass.
• 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 moethods.)
  • 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 object.
  • Is there some "root" object class?
  • ...