CSC207.01 2014F, Class 14: Interfaces and Polymorphism
- Upcoming Work.
- Extra Credit.
- Quick notes on Exceptions.
- Questions on Interfaces and Polymorphism.
- New lab partners tomorrow!
- Reminder: You can get extra credit by providing useful links.
- If you email me that your code doesn't work, it helps if you tell me a
case in which it doesn't work. (I'm often good at finding some cases, but
I'm more efficient if you give me clear details, and I think you'd rather
that I be efficient.)
- Good luck getting home SZ!
- Get flu shots. Make your mentor happy.
Extra Credit Opportunities
- Convo Wednesday.
- CS extras Thursday: EF, AHD, ZW and more on MIST.
- CS Table, Friday: ???
- Town hall meeting, 7:30 p.m. next Tuesday (the 30th, I hope)
- Science poster session on Saturday.
- Participate in #GrinWell.
- 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.
- How do we know that our code is efficient?
Quick Notes on Exceptions
When should I declare that my procedure throws exceptions?
When you note that there is a possibility that your procedure can
Can't every procedure fail?
There are procedures that never fail if their preconditions are met.
There are procedures whose failure is conceptually so rare that it's
not worth indicating.
And there are certainly some procedures that should never fail. If
I'm writing a
sort(int arr) method, there aren't any clear cases
in which it should fail.
When should I throw an exception?
When you've identified that an error has occured.
When should I use a try/catch clause?
When you are calling code that can fail and there is something you
can reasonably do in reaction to the exception. For example, you
might do an alternate computation, you might want to log an error,
or you might want to throw a different exception.
When should I simply pass along exceptions?
When the failure of a method you are calling will cause your method
to fail, and you consider it appropriate for your client to get the
same exception that you got. I'll note that it's rare that code
simply passes along exceptions. (It's an exception to pass exceptions.)
Why don't I have to catch
Java has a set of exceptions that they call
need not be caught, but can be caught. I think the designers decided
the forcing programmers to catch these would mostly clog up code and
frustrate competent programmers who would never do things that would
never result in such exceptions.
Questions on Interfaces and Polymorphism
- Talk to your partner.
- What did you see as the main points in the reading? (Be prepared
- What, if anything, was confusing about the reading? (Feel free to
post to the question board.)
- What's the point of an interface?
- A formal way to separate what from how.
- Once you can replace the implementation, you have a step toward
- It's better than inheritance because there's often no one way to
- Isn't an interface extra coding, since you have to write the same
things twice (or more)?
- Yes, it's extra coding, but there's almost no code in the interface.
- Long term, it's worth the extra work.
- Particularly useful on big projects.
- When should I make interfaces?
- You're about to design objects. You think first about their
capabilities. Why not do an interface?
- When you are writing code that you want to be general. E.g.,
What do I need to compute square roots?
- Polymorphic objects: Text blocks
- Sorry, SZ, it's on the whiteboard. Here's my attempt to summarize.
- We want to think about how to represent a block of text.
- Three natural methods