Overview

• Preliminaries.
  • Admin.
  • Upcoming Work.
  • Extra Credit.
  • Questions.
• Lessons from Inheritance Lab.
• Four ways to double counters.

Preliminaries

Admin

• Continue with yesterday's lab partners.
• I added some purple themes to our Web site. Are you happy? Apparently not. EE will send new colors. Other people will learn to customize their browsers for other fonts.
• I received my first recommendation of an external resource. I didn't particularly like it, but the person still received the credit. Telling me why you like resources would be helpful.
• At some point, we should talk about the best due date for the midsem. Many of you will be out of town the previous week.
• Wednesday's lab highlighted some differences in programming style between Prof. Rebelsky and Prof. Walker. We'll talk through those differences.
• It's Friday. I hope you have a chance to restore this weekend. Please be thoughtful about your choices this weekend (and not just because there are lots of families on campus).

Upcoming Work

• HW 6 due next Tuesday.
  • Prologue issues seem to be mostly "I have to understand both interfaces and inheritance" and "I don't know the built in Java data structures well enough".
    • One of the four or so I mention will probably work. In part, your choice will depend on how you like to think about data. If you like indexing ....
• Readings for Monday
  • Java Generics
  • You may also find the Java trail on generics useful: http://docs.oracle.com/javase/tutorial/java/generics/index.html

Extra Credit Opportunities

Academic

• CS table today: Big Data in the Social Sciences and Privacy
• Learning from Alumni Tuesday: Ian Bone (in person)
• Town hall meeting, 7:30 p.m. next Tuesday
• CS extras next Thursday: Alumni
• CS table next Friday: Serendipity and Computing (with Grinnell's Artist in Residence)
• Grinnell Prize Events the following week

Peer Support

• Science Poster Session, Saturday at 9:00.
• Soccer probably 11am Saturday.
• Orchestra, 2pm on Saturday

Miscellaneous

• Participate in #GrinWell http://www.grinnell.edu/forms/sign-grinwell-presidents-wellness-challenge
• Friends of Drake Library needs help setting up for their annual booksale on Thursday, October 2 (conveniently, the same night as Grinnell High School's homecoming parade). You can help a good cause and probably get a few free books, too.
  • Followup: They can also use help on Wednesday, October 1.

Questions

Lessons from the Inheritance Lab

Some questions and lessons from the lab on inheritance.

• Talk through each set with your partner(s).
• Be prepared to discuss with the class.

Consider these declarations

    public class Super
    {
      ...;
    } // class Super
    public class Sub
      extends Super
    {
      ...;
    } // class Sub
    Super fluous = new Super(...);
    Sub marine = new Sub(...);

• Can I use marine in places where the code wants an object of type Super? Why or why not?
  • Yes.
  • Sub extends Super, so Java it allows it.
  • We assume that anything in the subclass has all of the characterisitcs/methods of the parent class.
• Can I use fluous in places where the code wants an object of type Sub? Why or why not?
  • No.
  • We expect certain things of Subs, and Supers may not have all of those things. E.g., if there's a method in Sub that's not in Super, it will be strange to ask for fluous.method().
• What are some kinds of "places where the code wants an object of type Super"?
  • E.g., "I want a Counter". That means that I can use a DecrementableCounter also.
  • E.g. Super califragilistic = ...
    • Variable
    • Field
  • Return type from a method. Super woman() can return a Sub.
  • Parameters to a method. process(Super x) can take a Sub as an input.

Suppose we write

    Super fluous = new Super(...);
    Sub marine = new Sub(...);
    Super sonic = marine;
    pen.println(sonic.toString());

• If both Super and Sub provide toString methods, when I call sonic.toString(), which method do I get? Why?
  • Super.toString because Java thinks that sonic is a Super
  • Sub.toString because Java will analyze our code and figure it out
  • Sub.toString because Java is dealing with a particular object. And, even though Java athinks sonic is a Super, it's really a Sub.
  • Expermentally showed that it's Sub.toString.
  • Diagram of memory shows what's happening.
  • The determination of method is made by the object, not by the caller.
• What if we cast marine during the assignment or print?
  • Super sonic = (Super) marine;
  • pen.println((Super) marine);
• If only Sub provides a method, system(), can I call sonic.system()?
  • Yes, the object we're dealing with is a Sub, so we should be able to use it.
  • No. My experiment showed otherwise. (If you have a variable of type Counter that refers to a DecrementableCounter, you can't call the decrement method. This is similar.)
  • Hmmm ... is there a difference between methods we replace and methods we add?
    • Yes. The compiler knows that the objects have the methods that we replace, but it may not know that it has the objects we add.
• If the implementation of Sub.system includes a call to toString, how does the programmer implementing Sub.system indicate whether he/she/ze wants to use Sub.toString or Super.toString?
  • this.toString
  • super.toString
• How can the client indicate which version of toString to use?
  • He/she/ze can't

Examples in /examples/SuperSub

Constructors

• What have you learned about constructors for subclasses?

Additional Information

• What else did you learn about inheritance?

Four (or more) Mechanisms for Doubling Counters

Remember

public class Counter
{
  ...
  public String toString()
  {
   ...
  } // toString()

  public void increment()
  {
    ...
  } // increment()

  public void reset()
  {
    ...
  } // reset()
} // class Counter

Suppose we want another counter that counts twice as fast. What approaches might we take?