Examples For Typical Use of Abstract Classes and Interfaces

I am often asked to give examples of typical situations where abstract class and interfaces are used.
The data access object is a typical example of an interface or abstract class? I incline to say it is an interface. Please comment.

An interface tells you about a set of methods that an implementing object promises to implement. So it tells you something about an object without telling you exactly what class the object is. This kind of "information hiding" is key to decoupling classes so one class can survive changes in another class or work with new classes it never heard of without breaking. For examples, browse the JDK JavaDoc ... all the class names in italics are interfaces.
An abstract class goes a bit further in that it can provide default implementation of some or all methods. This is commonly used in "frameworks" that provide some functionality but expect you to override other methods to fill in the details.
Sometimes you'll see both in a toolkit. For example in Swing there is an interface for mouse event handlers. To make an event handler you could implement the interface which would require you to implement every method defined on the interface whether you care about those events or not. Swing sometimes provides an abstract default implementation, too. They implement all the methods, satisfying the interface requirements, with code that does nothing. Now if you want to make an event handler, you can extend the abstract default and override only the one method you care about.
One other interesting difference is a class can only extend one abstract class, restricting its place in your design. But a class can implement any number of interfaces. If you already have a class that must extend something else, you can easily make it implement new interfaces.
Hope that helps!

I like Stan's description quite a lot. Yes, I'd reinforce the idea that you should *prefer* coding to interfaces rather than abstract classes... using abstract classes *only* when you really do need functionality (ie. method implementations) that the subclasses need and are not expected to implement on their own, or you need to guarantee something about the implementations of the subclasses (but ideally, your design will probably prefer that you say as little as possible about the *actual* implementations used by implementing classes).
I like to think of it this way:
* Abstract class -- defines what you ARE
(a Dog, a kitchen appliance, a GameCharacter, etc.)
* Interface -- defines what you can DO, a ROLE you can play regardless of WHAT you are
(a Pet [something that can do pet behaviors], a Runnable [something that can be run in a separate thread], a Serializable [something that can be Serialized], a Syrupable [something upon which you can use maple syrup

-- a criteria I use at breakfast time])
cheers,
Kathy

Good distinction. I started a tutorial on this one with a goofy metaphor. I'll keep it in the "ranch" theme a bit ...
Say I'm casting a movie. I put out a call for Actors. Let's say Actor is WHAT THEY ARE. That means they have some skills, qualifications, union membership, etc. (Of course in real life a human IS many things so this metaphor does not stretch very well.)
I need an actor who can ride a horse, play guitar and sing cowboy songs. A given actor might come in and say "Yes, I can ride a horse" or "Nope, can't play guitar". Those "interfaces" tell me what he claims he can do.
I might want to run some "unit test" auditions and see just how well he rides. Ok, the metaphor snaps about here.
Happy trails!